@guanlin4924/devflow-pi 0.1.85 → 0.1.88

package/plugins/devflow-quality/skills/workflow-gen-test-guide/legacy/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: workflow-gen-test-guide
+description: "从需求(PRD/baseline/功能点梳理)生成检查点树形态的测试指导书——每个可测点展平成树的叶子检查点(一句话,不埋进用例字段块),按【测试视角分层】(前台/后台/服务与数据/边界场景/风险覆盖/待确认/埋点/缺少内容)组织,组件按状态/维度深拆(目标5-7层),PRD全覆盖(漏的进待确认分支),站高级测试工程师视角。产出的测试指导书.md是检查点树形态,供change-xmind转成xmind思维导图。"
+argument-hint: "<功能名> [@PRD文档.md 或 语雀URL] [--auto]"
+user-invocable: true
+pattern: generator
+inputs:
+  - ".planning/features/{feature}/功能点梳理.md"
+  - ".planning/requirements/baseline.md"
+  - ".planning/PROJECT.md"
+  - "可选 PRD 原文（仅在当前步骤明确提供时读取）"
+output: ".planning/features/{feature}/测试指导书.md"
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+---
+
+# 检查点树生成 Skill
+
+> Devflow 适配说明：本文件随插件分发，由上层适配器调用。项目事实统一位于 `.planning/`；执行时以本文件的 Devflow 路径和适配器传入的输入为准，不解析旧版的 `_shared/` 或机器本地路径。
+
+This skill consumes 需求(PRD/baseline/功能点梳理) and creates a **检查点树**(checkpoint tree)——每个可测点展平成树的叶子检查点(一句话,可勾可数),**不是**用例字段块形态。Do not re-discuss requirements or generate technical plans.
+
+产出形态参考(用户要的):叶子是一句话检查点(如"点击气泡不进行签到时星辉余额未变化"),按 **测试视角分层** 组织:`测试视角层(前台/后台/服务与数据/边界场景/风险覆盖/待确认/埋点/缺少内容) → 功能模块 → 子模块/组件 → 状态/维度分叉 → 条件 → 叶子`。**标题纯语义名,不带 FP 编号、不带章节号**(FP 仅留文末覆盖核对表)。组件有多个状态/维度时**先拆分叉再挂叶**(宁可深不要扁,目标 5-7 层)。change-xmind 读这个 md 的缩进结构转成 xmind。
+
+<workspace_config>
+## Workspace Root 解析
+
+Devflow 由 Runtime 传入当前项目根目录和 feature，不再解析旧版 `WORKSPACE_ROOT` 参数。
+
+路径约定：
+- **共享文件**: `.planning/` — PROJECT.md, STATE.md, navigation/
+- **功能文件**: `.planning/features/{feature}/` — baseline.md, 功能点梳理.md, 测试指导书.md, etc.
+</workspace_config>
+
+## Outputs
+
+Always create or update:
+
+- `.planning/features/{feature}/测试指导书.md`（**检查点树形态**,非用例字段块形态。供 change-xmind 转 xmind）
+
+> 本 skill 产出**检查点树**:每个可测点是树的一句话叶子,按 `测试视角层→功能模块→子模块/组件→状态/维度分叉→条件→叶子` 组织,**标题纯语义名(无 FP/章节号)**。**不产**用例字段块形态(无 优先级/关联/前置/步骤/预期 块)。
+
+## Argument Handling
+
+- `<功能名>`: 由 Devflow 当前 feature 提供，用于定位 `.planning/features/{feature}/` 和输出路径。
+- `@PRD文档.md` 或 `语雀URL`: 可选,PRD 原文(feature-breakdown 缺失时作为可测点源头,有则始终读作覆盖核对基准)。
+- `--auto`: do not ask for supplementary information; mark gaps as `待确认` 进 PT-xxx 分支。
+
+## 输出形态全局声明（重要，覆盖所有 slot 的历史措辞）
+
+本 skill 产出**检查点树叶子**(一句话,动词起头,不带字段块,不带"测试"后缀)。`test-type-slots/` 下的 slot 文件是历史用例形态,其中的 `Test case / xxx测试 / Required Fields(前置/步骤/预期)` 是**历史措辞,已废弃**——以 `common-test.md` 和 `writing-guide.md` 的叶子规范为准。
+
+slot 的**展开规则逻辑**(界内/界上/界外、正常/异常、状态流转、必填/可编辑/枚举等)原样复用,只是产出形态从"用例"变"叶子"。例如 boundary-test 的"→ 界外: 0 — '分成比例0阻断提交测试'" 实际产出叶子 `- 分成比例输入0时阻断提交`(去掉"测试"后缀,动词起头)。
+
+## Resource Loading
+
+Load bundled resources only when needed:
+
+- Read `references/writing-guide.md` before writing any checkpoint leaf.
+- Read `references/bug-rules.md` before expanding permissions, read-only fields, calculations, or enum values.
+- Read `references/exception-checklist.md` when the feature involves user flows, payment, third-party callbacks, retries, async status, or data consistency.
+- Read `references/coverage-checklist.md` before Phase 6 coverage check.
+- Read `references/test-type-slots/common-test.md` always — it applies to all checkpoint types.
+- Read `references/test-type-slots/ui-test.md` when expanding `- 样式` / `- 样式验证` nodes.
+- Read `references/test-type-slots/function-test.md` when expanding `- 功能` / `- 功能验证` nodes.
+- Read `references/test-type-slots/scenario-test.md` when expanding normal end-to-end flows.
+- Read `references/test-type-slots/exception-test.md` when expanding exception/error/failure/concurrency nodes. Use `references/exception-checklist.md` to identify exception scenarios.
+- Read `references/test-type-slots/boundary-test.md` when expanding numeric/time/state/capacity boundary nodes.
+- Read `references/test-type-slots/compatibility-test.md` when expanding old/new migration, data initialization, cutover, or legacy compatibility nodes.
+- Read `references/test-type-slots/performance-test.md` when expanding time-bound tasks, large data exports, batch jobs, or concurrency load nodes.
+- Read `references/test-type-slots/data-test.md` when expanding `- 逻辑` / `- 逻辑验证` nodes or calculation rules.
+- Read `references/test-type-slots/api-test.md` when expanding `API/服务` nodes.
+- Read `references/test-type-slots/security-test.md` when expanding `权限` / `审计` nodes.
+- Read `references/test-type-slots/integration-test.md` when expanding cross-module nodes.
+- Read `references/test-type-slots/usability-test.md` when expanding `防重复` / `提示` / `埋点` nodes.
+- Read `assets/output-template.md` before writing the final document.
+
+## Phase 1 — Load Input Documents
+
+源头优先级(feature-breakdown > baseline > PRD 原文),按可用性读:
+
+1. Read `.planning/features/{feature}/功能点梳理.md` — 首选(字段级三维叶子,可测点素材)。
+2. Read `.planning/requirements/baseline.md` — FP/BR/BC/CR 清单 + 澄清过的规则。
+3. Read `.planning/PROJECT.md` — 项目上下文 + 代码路径(Phase 1.5 用)。
+4. **Read PRD 原文**(语雀 URL 或 `@文件.md`)— 始终读,作为覆盖核对的基准。feature-breakdown/baseline 缺失时,PRD 是可测点的唯一源头。
+5. 若 feature-breakdown 和 baseline 都缺失且无 PRD → 报错,要求用户提供需求来源。
+
+## Phase 1.5 — Code Context Enrichment (Conditional)
+
+This phase runs ONLY when PROJECT.md "Project Locations" table contains at least one local path that is not `待确认`, `pending`, `无`, or `none`. If no code paths are available, skip this phase entirely and continue to Phase 2.
+
+### 1.5.1 Load Navigation Files
+
+If code paths exist:
+1. Read `.planning/navigation/INDEX.md`.
+2. Follow only navigation documents linked from INDEX.md; do not require fixed FRONTEND.md, ADMIN.md, or BACKEND.md filenames.
+3. Extract concrete directory paths for components, pages, routes, controllers, services, models/entities, and enums/constants from the available navigation documents.
+4. If a category is absent, record it as unavailable rather than inventing a path.
+
+### 1.5.2 Enum & Status Probe
+
+For each place where `bug-rules.md` demands concrete enum values (dropdowns, status fields, type fields):
+
+1. Use `Grep` to search backend source for enum definitions matching status/type fields in the current feature:
+   - Search patterns: `enum`, `const.*STATUS`, `statusMap`, `STATUS_MAP`, `status_map`, `Map<String`
+   - Limit: `--max-count 10` per pattern
+2. Use `Grep` to search frontend/admin source for status display mappings:
+   - Search patterns: `statusText`, `statusLabel`, `statusMap`, `getText`, `map[`
+   - Limit: `--max-count 10` per pattern
+3. Build concrete enum map: `{ enum_name: [value1, value2, ...] }` with source file + line for traceability.
+
+### 1.5.3 Validation Rules Probe
+
+For each form field or input mentioned in feature-breakdown/PRD:
+
+1. Use `Grep` to search frontend/admin source for validation rules:
+   - Search patterns: `required`, `maxLength`, `minLength`, `pattern`, `validator`, `rules`
+   - Target: form/rule/validate directories identified in navigation files
+   - Limit: `--max-count 5` per field
+2. Extract concrete rules: `{ field_name: { required: true, maxLength: 20, ... } }`
+
+### 1.5.4 API Shape Probe
+
+For each API/service node in feature-breakdown/PRD (when `api-test.md` slot applies):
+
+1. Read controller/handler files identified in BACKEND.md.
+2. Extract: endpoint path, HTTP method, request DTO fields, response DTO fields.
+3. Build API fact sheet: `{ endpoint: { method, request_fields, response_fields } }`
+
+### 1.5.5 Route & Page Existence Probe
+
+For each page/route mentioned in feature-breakdown/PRD:
+
+1. Use `Glob` to verify page component files exist.
+2. Use `Grep` to check route definitions in router files.
+3. Record: `{ page_name: { exists: true, path: "..." } | { exists: false } }`
+
+### 1.5.6 Build Code Context Summary
+
+Consolidate findings into an internal "Code Context Summary" (NOT written to disk, used internally in Phase 4 to make checkpoint leaves concrete — enum values, validation rules, API shapes all flow into leaf descriptions):
+
+```markdown
+## Code Context Summary
+
+### Enums Resolved
+| Enum Name | Values | Source File |
+|-----------|--------|-------------|
+
+### Validation Rules Found
+| Field | Rules | Source File |
+|-------|-------|-------------|
+
+### API Endpoints
+| Endpoint | Method | Request Fields | Response Fields |
+|----------|--------|---------------|-----------------|
+
+### Pages Verified
+| Page | Exists | Path |
+|------|--------|------|
+
+### Unresolved (still 待确认)
+| Item | Reason |
+|------|--------|
+```
+
+## Phase 2 — 提取 PRD 可测点
+
+目标:把 PRD 的每个可测点提取出来,作为检查点树叶子的源头。**不丢弃任何 PRD 提到的项。**
+
+### 2.1 确定源头
+
+按 Phase 1 读取的可用性,feature-breakdown 产出(字段级三维叶子)是首选素材,baseline 补充规则,PRD 原文始终作为覆盖核对基准。真实场景常是用户直接给 PRD(没跑 feature-breakdown),此时 PRD 是唯一源头。
+
+### 2.2 提取可测点清单
+
+从源头逐项提取,每项标注来源章节(用于 Phase 6 反向核对):
+
+- **字段**(从字段表):每个字段记录 {字段名, 类型, 是否必填, 是否可编辑, 限制(长度/精度/范围), 枚举值}
+- **规则**(从业务规则/校验段):每条规则(如"概率总和必须100%""兑奖码只能增加不能减少")
+- **流程**(从业务流程图):主流程 + 异常分支,记录每个状态流转
+- **异常**(从异常处理表):每行一个异常场景(如"支付成功但兑奖码分配失败")
+- **配置项**(从配置段):每个可配置项及其约束
+- **非功能**(性能/安全/合规要求)
+
+输出内部 **可测点清单**(不落盘),每项带 PRD 章节号或 FP 编号。
+
+## Phase 3 — 按测试视角分层 + 状态/维度深拆（核心，决定树拓扑）
+
+把可测点组织成检查点树层级(对齐 output-template)。**一级是测试视角分层(非 PRD 模块集合),组件按状态/维度深拆(非直接挂叶),标题纯语义名(无 FP/章节号)。**
+
+### 3.1 一级:测试视角分层（canonical 8 分支，固定顺序，空则省略）
+
+按**测试角度**切一级(不按 PRD 章节号、不按"端"打包所有可测点)。固定 8 分支,**按此顺序**,没内容的省略:
+
+1. **前台** — C 端用户可见页面/交互/状态展示(签到入口、日历页展示、签到执行、连签·断签·预估、账号合并、会员预留等用户视角的功能验证)。
+2. **后台** — 运营配置/管理页/规则生效/统计/权限矩阵。
+3. **服务与数据** — 接口与幂等、计算规则、断签判定、奖励计算、数据迁移、账号合并(数据层)、安全(未登录/越权)、性能(响应目标/并发/高峰)。
+4. **边界场景** — 跨层边界值:时间边界(自然日/0 点切换)、数据边界(封顶/极值)、异常场景(接口超时)、历史兼容(旧数据/旧版用户)。
+5. **风险覆盖** — 风险点 → 覆盖它的检查点(按名引用)索引 + 完整性结论。**不复制别处叶子原文**(见 3.6 归位规则)。
+6. **待确认** — PT-xxx(PRD 未明说但该测/依赖外部确认)。
+7. **埋点** — 曝光/点击等埋点检查(无内容则省略)。
+8. **缺少内容** — PRD 缺失、需补充的明确占位(无内容则省略)。
+
+> **PRD 章节号不再是主键**。PRD 章节号只作 Phase 6 反向核对来源标记,记进覆盖核对表(不进树标题)。
+
+### 3.2 二级:功能模块
+
+每个测试视角层下,按 PRD 章节的**语义名**挂功能模块节点(**不带章节号、不带 FP**):如前台下的 `签到入口 / 日历页展示 / 签到执行 / 连签·断签·预估 / 账号合并 / 会员预留`;后台下的 `配置页 / 规则生效 / 统计 / 权限矩阵`。从 PRD 章节标题提炼语义,去掉编号。
+
+### 3.3 三级:子模块/组件
+
+功能模块下挂子模块或组件节点:如 `签到入口 → 储蓄罐气泡 / 首页个人信息入口`;`日历页展示 → 连签信息区 / 激励提示 / 签到按钮 / 规则 / 日历面板 / 日期状态 / 月份切换 / 加载失败`。
+
+### 3.4 四级:状态/维度分叉（深度主驱动，有自然轴必须拆）
+
+组件下**先按状态或维度拆分叉节点,再挂叶**(宁可深不要扁)。**禁止组件下直接平铺叶子**——只要有 ≥2 个状态/维度就必须建分叉层。
+
+- **状态轴**:未签/已签;今日未签/今日已签/历史已签/历史未签/未来日期;新增/编辑/查看;开关开/关;成功/失败。
+- **维度轴**:交互/逻辑调整/展示;数值核算/展示内容;入口/权限;正常场景/异常场景;配置/校验/保存。
+
+例:`储蓄罐气泡 → 交互 / 逻辑调整`;`逻辑调整 → 点击气泡不进行签到`;`签到按钮 → 未签 / 已签`;`日期状态 → 今日未签 / 今日已签 / 历史已签 / 历史未签 / 未来日期`。
+
+### 3.5 五级+:条件 → 叶子
+
+分叉节点下挂条件节点(如 `点击气泡不进行签到`)或直接挂一句话叶子。条件节点下再挂叶子(如 `点击气泡不进行签到 → 星辉余额未变化 / 未产生星辉流水 / 不产生签到记录 / 不出现签到成功提示 / 返回首页气泡仍展示未签到状态`)。**目标 5-7 层、平均 6+。**
+
+### 3.6 跨切层归位规则（检查点放"主要测试角度"，不重复）
+
+同一检查点可能既属 UI 层又属边界,按**主要测试角度**归位、**不重复**:
+
+- **UI 交互/状态展示验证** → 前台(如"点击今日日期完成签到")。
+- **时间/数据边界值**(自然日切换、封顶、极值) → 边界场景(如"23:59 签到记为当天")。
+- **接口幂等/计算/迁移/安全/性能** → 服务与数据(如"同用户同日并发只发一次奖励")。
+- **风险覆盖层** 只放 `风险 → 覆盖:[检查点名1/检查点名2] + 完整性结论` 的**索引叶子**,引用别处已存在的检查点名,**不复制叶子原文**。例:`奖励重复发放 → 覆盖:重复签到/防重复提交/幂等接口/并发;C 端和接口均覆盖`。
+
+> 归位有歧义时,默认归到"最贴近用户可感知行为"的层(UI 感知→前台,纯数据→服务与数据,边界值→边界场景)。
+
+
+## Phase 4 — 按 slot 展开叶子
+
+加载相关 `references/test-type-slots/*.md` + `references/bug-rules.md` + `references/exception-checklist.md`。对 Phase 2 的每个可测点,按 slot 规则展开成**一句话叶子检查点**(不是用例)。
+
+展开规则(按可测点类型):
+
+- **字段** → boundary-test + function-test slot:必填校验叶 + 可编辑性叶 + 类型校验叶 + 边界值叶(0/负数/极值/精度,**每个独立**) + 枚举值叶(列具体值)
+- **规则** → 校验叶子(把规则转成"X 时阻断/通过"叶)
+- **流程** → scenario-test slot:拆成状态流转节点 + 每状态/关键动作一叶(**不整条一个叶**)
+- **异常** → exception-test slot:每条异常一个叶("X 异常时 Y")
+- **配置项** → 字段验证叶子
+- **权限** → security-test slot + bug-rules 第1条(无权限=**不显示**,不是置灰)
+- **数据/计算** → data-test slot:每个计算规则一叶
+
+应用 bug-rules(7 条)作叶子质量约束:权限不显示、只读默认、计算引原文、枚举具体、同名字段独立、按前后台分模块。
+
+**不合并**(writing-guide):边界值/相近操作每个独立成叶。
+
+**Code Context 集成**(Phase 1.5 有产出时):用具体枚举值/校验规则/API 形状让叶子具体(不写"枚举待确认",写"枚举值为[现金支付模式,闲鱼模式]")。
+
+**FP 编号不进任何节点标题**(`参与模式配置` 而非 `参与模式配置（FP-001）`)。FP 仅在 Phase 6 覆盖核对表里做追溯映射。标题一律纯语义名,同样不带章节号(1.1/2.1)。
+
+## Phase 5 — 输出检查点树
+
+加载 `assets/output-template.md`。按其层级约定写 `.planning/features/{feature}/测试指导书.md`(文件名保留,内容是检查点树形态):
+
+1. 来源信息
+2. 检查点树(Phase 3-4 组织的 **测试视角层→功能模块→子模块/组件→状态/维度分叉→条件→叶子** 缩进结构,标题纯语义名)
+3. 覆盖核对表(Phase 6 产出;FP 编号/PRD 章节号**仅存活于此**)
+4. 待确认测试项(PT-xxx):PRD 未明说但该测的、依赖外部确认的,单列**不丢**
+5. 末尾 `<!-- gate-review -->` 块
+
+change-xmind 读这个 md 的缩进结构转成 xmind。
+
+## Phase 6 — Quality Check (MANDATORY — do not skip)
+
+加载 `references/coverage-checklist.md` + `references/writing-guide.md`。
+
+### 6.1 形态检查
+
+- [ ] 所有叶子是一句话,无字段块残留(无 优先级/关联/前置/测试步骤/预期结果)
+- [ ] 边界值未合并(每个边界独立成叶)
+- [ ] 流程已拆成状态流转节点,不是整条一个叶
+- [ ] **顶层是测试视角分层**(前台/后台/服务与数据/边界场景/风险覆盖/待确认/埋点/缺少内容),非 PRD 模块集合、非按"端"打包
+- [ ] **组件下有 ≥2 状态/维度时已建四级分叉层**,未直接平铺叶子(状态/维度深拆)
+- [ ] **标题纯语义名,无 FP 编号、无章节号(1.1/2.1)残留**(FP/章节号只在覆盖核对表)
+- [ ] **深度达标**:平均 ≥6 层、最大 ≥7 层(宁可深不要扁)
+- [ ] 叶子无模糊词("大概"/"可能"/"或"/"应该")
+
+### 6.2 覆盖核对 (MANDATORY — 用户的硬要求)
+
+按 coverage-checklist:
+
+- [ ] **PRD 章节覆盖率 100%**(每个 PRD 章节都有对应分支)
+- [ ] FP 覆盖率 ≥95%(P0 FP 100%)
+- [ ] **无静默丢弃**:漏项都进了 PT-xxx 分支或有明确说明
+
+### 6.3 内容检查
+
+- [ ] 权限叶子用"不显示"不用"置灰"(bug-rules)
+- [ ] 枚举叶子列了具体值(不写"系统枚举")
+- [ ] 计算叶子引了 baseline/PRD 原文依据
+- [ ] 同名字段不同页面独立检查
+
+不通过 → 补全后重跑,不标"通过"。
+
+## Phase 7 — Review Gate
+
+### 7.1 覆盖审查
+
+- PRD 每个章节都有对应分支?
+- 每个 FP 有对应节点?
+- 漏项都进了 PT-xxx(没静默丢)?
+
+### 7.2 形态审查
+
+- 抽查 5 个叶子,确认是一句话、无字段块、可观察可验证
+- 抽查 3 个组件,确认按状态/维度拆了四级分叉(非直接平铺叶子)
+- 抽查全树,确认顶层是测试视角分层、标题无 FP/章节号、平均深度 ≥6
+
+### 7.3 Review Conclusion
+
+在 `测试指导书.md` 末尾写 `<!-- gate-review -->` 块,check-items 含:PRD章节覆盖率100% / FP覆盖率≥95% / 无静默丢弃 / 叶子无字段块残留 / 边界未合并 / **顶层测试视角分层** / **组件状态/维度深拆** / **标题无FP/章节号** / **平均深度≥6**。
+
+**Do not report completion until Phase 6 覆盖核对通过 且 gate-review check-items 全通过。**

package/plugins/devflow-quality/skills/workflow-gen-test-guide/legacy/assets/output-template.md

@@ -0,0 +1,213 @@
+# 检查点树：{{功能名称}}
+
+> 本文档是**检查点树**(不是测试用例文档)。每个可测点展平成树的叶子,一眼可见、可勾、可数。change-xmind 会把本文档的缩进结构转成 xmind 思维导图。
+
+## 一、来源信息
+
+- **需求来源**：`{PRD路径 / baseline路径 / 功能点梳理路径}`
+- **功能名称**：{{功能名称}}
+- **生成时间**：{{日期}}
+- **代码上下文**：{{已使用（枚举/校验/API 来自源码）/ 无本地代码（纯文档模式）}}
+
+## 二、检查点树
+
+**层级约定**(change-xmind 按此解析,**目标 5-7 层、平均 6+,宁可深不要扁**):
+- `### 测试视角层`(前台/后台/服务与数据/边界场景/风险覆盖/待确认/埋点/缺少内容) → 一级(空的省略,固定顺序)
+- `  - 功能模块` → 二级(纯语义名,不带章节号)
+- `    - 子模块/组件` → 三级
+- `      - 状态/维度分叉`(未签/已签、今日/历史/未来、交互/逻辑调整、正常/异常...) → 四级(**有 ≥2 个状态/维度必须拆,禁止直接平铺叶子**)
+- `        - 条件` → 五级(可选,如"点击气泡不进行签到")
+- `          - 一句话检查点叶子` → 六级+(最末端)
+
+> **标题纯语义名**:不带 FP 编号、不带章节号(1.1/2.1)。FP/章节号只在「三、覆盖核对」表里做追溯。
+> **跨切层归位不重复**:UI 交互验证归前台;时间/数据边界值归边界场景;接口幂等/计算/迁移/安全/性能归服务与数据;风险覆盖层只放「风险→覆盖检查点名索引」,不复制叶子原文。
+
+### 前台
+
+- 签到入口
+  - 储蓄罐气泡
+    - 交互
+      - 气泡正常展示
+      - 点击气泡拉起签到日历
+    - 逻辑调整
+      - 点击气泡不进行签到
+        - 星辉余额未变化
+        - 未产生星辉流水
+        - 不产生签到记录
+        - 不出现签到成功提示
+        - 返回首页气泡仍展示未签到状态
+  - 首页个人信息入口
+    - 入口
+      - N天入口和箭头可见
+      - 点击进入签到日历页
+    - 签到/未签到
+      - 日历页签到后返回首页查看数值变化
+        - 天数正常+1
+      - 日历页不签到返回首页查看数值变化
+        - 天数不变(当前为未签到状态)
+- 日历页展示
+  - 连签信息区
+    - 展示内容
+      - 当日未签到
+        - 当天前有连续签到时正常展示连签天数数值
+        - 当天前无连续签到时展示0
+        - 进行签到后连签天数数值正常+1
+      - 当日已签到
+        - 同上(已签状态展示连签天数)
+    - 数值核算
+      - 核算用户连签天数正确性
+      - 日历展示对应连签天数状态正常
+  - 激励提示
+    - 未签
+      - 显示"今日签到可得X星辉"
+        - X与当前连签对应奖励一致
+    - 已签
+      - 切换为"明日继续签到可得X星辉"
+        - X与明日连签对应奖励一致
+  - 签到按钮
+    - 未签
+      - 按钮高亮
+      - 展示"立即签到"
+    - 已签
+      - 按钮置灰
+      - 展示"今日已签到"
+  - 日期状态
+    - 今日未签
+      - 今日日期高亮
+      - 展示+X星辉预估
+      - 点击今日日期可完成签到
+    - 今日已签
+      - 显示打勾图标
+      - 展示已获得星辉数
+      - 点击提示"今日已签到"
+    - 历史已签
+      - 显示打勾+获得星辉数
+      - 点击无反应
+    - 历史未签
+      - 置灰+打叉标记"未签"
+      - 点击无反应
+    - 未来日期
+      - 浅灰空状态
+      - 展示预估星辉数
+      - 不可点击
+- 签到执行
+  - 正常签到
+    - 点击"立即签到"弹窗显示"签到成功+X星辉"
+    - 今日日期格变为已签打勾
+    - 连签天数+1
+    - 星辉余额增加X
+  - 重复签到
+    - 提示"今日已签到"
+    - 星辉余额不增加
+    - 今日只有一条有效记录
+  - 异常场景
+    - 网络异常
+      - 展示"请稍后再试"
+      - 按钮恢复可点击
+    - 账户异常/风控限制
+      - 展示可理解失败提示
+      - 不新增有效记录
+
+### 后台
+
+- 配置页
+  - 奖励表编辑
+    - 新增行
+      - 支持天数+星辉数值
+    - 星辉数值校验
+      - 须为正整数
+      - 输入≤0时校验拦截并提示
+  - 保存与校验
+    - 点击保存弹出二次确认
+      - 弹窗文案"是否保存及次日生效"
+    - 校验拦截
+      - 签到天数重复时阻止保存并提示
+      - 规则文案为空时阻止保存且字段标红
+    - 保存中按钮置灰防重复提交
+- 权限矩阵
+  - 有配置权限运营
+    - 菜单可见
+    - 编辑/保存允许
+  - 只读运营
+    - 菜单可见
+    - 编辑/保存不显示按钮
+  - 无权限账号
+    - 菜单不显示
+
+### 服务与数据
+
+- 签到接口与幂等
+  - 签到提交接口
+    - 成功时新增一条有效记录
+    - 成功时新增一笔星辉流水
+    - 并发重复请求幂等只发一次
+- 奖励计算
+  - 按连签天数匹配后台配置的奖励阶梯
+  - 超过封顶天数固定封顶值
+  - 同用户同日只一条记录+一笔流水
+- 安全
+  - 未登录态
+    - 调用签到接口被拒绝
+    - 不写记录
+  - 越权访问
+    - 用A登录态请求B数据被拒绝
+
+### 边界场景
+
+- 时间边界
+  - 23:59签到记为当天(北京时间自然日)
+  - 0:01后显示昨日已签、今日可签
+- 数据边界
+  - 超过封顶天数奖励不变
+  - 连签天数继续累加
+
+### 风险覆盖
+
+- 奖励重复发放
+  - 覆盖:重复签到/防重复提交/幂等接口/并发
+  - C端和接口均覆盖
+- 规则变更追溯错误
+  - 覆盖:当天旧规则/次日新规则/历史不追溯
+  - 完整覆盖
+
+### 待确认
+
+- {{如"统计维度和导出字段范围——PRD未细化"}}
+- {{如"压测并发量标准——PRD只说需评估未给数值"}}
+
+## 三、覆盖核对
+
+> FP 编号 / PRD 章节号**仅存活于此表**,做追溯映射(不进树标题)。
+
+| PRD章节 / FP | 是否有对应分支 | 落点(测试视角层/功能模块) |
+|-------------|--------------|--------------------------|
+| 3.1 签到入口 / FP-001 | 是 | 前台/签到入口 |
+| 3.2 日历结构 / FP-002 | 是 | 前台/日历页展示 |
+| 3.4 签到逻辑 / FP-004 | 是 | 前台/签到执行 + 服务与数据/奖励计算 |
+| 5.1 后台配置 / FP-012 | 是 | 后台/配置页 |
+
+PRD章节覆盖率: X / Y (Z%)
+FP覆盖率: X / Y (Z%)
+
+## 四、待确认测试项（PT-xxx）
+
+PRD 未明说但测试建议覆盖、或依赖外部确认的项——**不丢弃,单列此处**(也对应树上 `### 待确认` 分支):
+
+- PT-001 {{如"并发签到的具体并发量级——PRD只说同用户并发只发一次"}}
+- PT-002 {{如"后台配置是否按平台/组织灰度——PRD 4.2与5.2表述冲突"}}
+
+<!-- gate-review
+review-status: 通过 / 不通过
+unresolved-items: {{未通过的检查项，无则写"无"}}
+reviewer: workflow-gen-test-guide
+check-items:
+  - PRD章节覆盖率100%: 通过/不通过
+  - FP覆盖率≥95%: 通过/不通过
+  - 无静默丢弃项(漏项都进了PT-xxx): 通过/不通过
+  - 叶子无字段块残留(无优先级/关联/步骤/预期): 通过/不通过
+  - 边界值未合并(每个边界独立成叶): 通过/不通过
+  - 顶层测试视角分层(非PRD模块集合): 通过/不通过
+  - 组件状态/维度深拆(四级分叉非平铺叶子): 通过/不通过
+  - 标题无FP/章节号(纯语义名): 通过/不通过
+  - 平均深度≥6: 通过/不通过
+-->

package/plugins/devflow-quality/skills/workflow-gen-test-guide/legacy/references/bug-rules.md

@@ -0,0 +1,9 @@
+# 核心规避规则（来自真实 Bug）
+
+1. **权限控制统一为"不显示"** — 无权限时操作按钮不显示，而非置灰或不可点击。测试用例必须验证按钮"不显示"，不能写成"不可点击"或"置灰"
+2. **只读字段不可推断为可编辑** — 功能点梳理中未明确说明可编辑的字段，测试用例中默认为"只读展示，不可编辑"
+3. **计算规则必须有原文依据** — 金额正负、余额计算、统计口径等规则必须来自 baseline 或功能点梳理，不能推断。测试用例中的计算公式必须标注来源（BR-xxx 或 Q-xxx）
+4. **同名字段在不同页面定义可能不同** — 同一字段名在不同页面可能有不同逻辑，测试用例不能跨页面复用字段定义
+5. **评审纪要的结论必须严格遵循** — 评审纪要中的规则优先级最高，测试用例必须完整体现
+6. **下拉选项必须列出具体枚举值** — 测试用例中下拉框的可选项必须列出具体值，不能写"系统枚举"或"待确认枚举"
+7. **功能模块按前后台分类组织** — C 端归 C 端，后台归后台，API/服务归 API/服务

package/plugins/devflow-quality/skills/workflow-gen-test-guide/legacy/references/coverage-checklist.md

@@ -0,0 +1,63 @@
+# 覆盖率检查清单（PRD章节 / FP 分支覆盖核对）
+
+## 目标
+
+保证 PRD 的每个章节、每个功能点(FP)、每个可测点都在检查点树中有对应分支或叶子——**不因"PRD没明说"就丢弃**。漏的项必须进"待确认测试项(PT-xxx)"分支,不允许静默消失。
+
+## 步骤 1：提取核对源清单
+
+从输入(PRD 原文 优先 / baseline.md / 功能点梳理.md)提取三份清单:
+
+1. **PRD 章节清单**:所有章节号 + 标题(如 `5.1 后台计划配置`、`5.1.2 计划类型`、`5.2.3 异常处理`)
+2. **FP 清单**:baseline 的所有 `FP-xxx` + 标题(若有 baseline)
+3. **可测点清单**:每个章节下的 字段/规则/流程/异常/配置项(从 PRD 的字段表、业务流程、异常处理表、配置项表逐项提取)
+
+## 步骤 2：反向核对
+
+对步骤 1 的每一项,核对是否在检查点树中有对应分支/叶子:
+
+- **PRD 章节核对**:每个章节(如 `5.1.2 计划类型字段表`)→ 树中是否有对应模块/文件夹
+- **FP 核对**:每个 `FP-xxx` → 树中是否有 `(FP-xxx)` 节点
+- **可测点核对**:
+  - 字段 → 是否有 必填校验/可编辑性/类型/边界/枚举 叶子
+  - 规则 → 是否有 校验叶子(如"概率总和100%")
+  - 流程 → 是否有 正常场景 + 异常场景 叶子
+  - 异常 → 是否有 异常场景叶子(每条异常一行)
+
+## 步骤 3：漏项处理（不丢弃,这是硬要求）
+
+漏的项**不删除**,按类型处理:
+
+| 漏项类型 | 处理 |
+|---------|------|
+| PRD 明确提到但展开不全 | 补叶子 |
+| PRD 没明说但测试该覆盖(并发/越权/时区/幂等) | 进"待确认测试项(PT-xxx)"分支,标注"PRD未明说,建议补充" |
+| 明确不在范围(预留功能) | 进"待确认"分支,标注"仅验证展示" |
+| 依赖外部确认(视觉稿/协议文案) | 进"待确认"分支,标注依赖项 |
+
+**绝不允许:静默丢弃 PRD 的任何一项。**
+
+## 步骤 4：输出覆盖核对表
+
+写入检查点树末尾(在"待确认测试项"分支之前):
+
+```markdown
+## 覆盖核对
+
+| PRD章节 / FP | 是否有对应分支 | 落点（测试视角层/功能模块,纯语义名） |
+|-------------|--------------|------|
+| 5.1 后台计划配置 | 是 | 后台/配置页 |
+| 5.2.3 库存校验 | 是 | 前台/购买限制 或 服务与数据/库存扣减 |
+| FP-009 库存扣减 | 是 | 服务与数据/库存扣减 |
+| 5.3.4 盲盒抽取-单次 | 是 | 前台/支付抽取 |
+
+PRD章节覆盖率: X / Y (Z%)
+FP覆盖率: X / Y (Z%)
+```
+
+## 覆盖率阈值
+
+- **PRD 章节覆盖率:必须 100%**(每个 PRD 章节都有对应分支——这是用户的硬要求)
+- FP 覆盖率:≥ 95%(P0 FP 必须 100%)
+- 漏项必须有去向(补叶子 或 进 PT-xxx),不允许"未覆盖且无说明"
+- 低于阈值 → gate-review 标"不通过",补全后重跑

package/plugins/devflow-quality/skills/workflow-gen-test-guide/legacy/references/exception-checklist.md

@@ -0,0 +1,37 @@
+# 异常场景检查清单
+
+当功能涉及用户流程、支付、第三方回调、重试、异步状态或数据一致性时，必须检查以下场景。
+
+## 用户主动操作类
+- [ ] 用户取消操作如何处理
+- [ ] 用户退出页面如何处理
+- [ ] 用户重复操作如何处理
+- [ ] 用户快速连续点击如何处理
+
+## 系统超时类
+- [ ] 支付超时如何处理
+- [ ] 接口超时如何处理
+- [ ] 回调超时如何处理
+- [ ] 任务执行超时如何处理
+
+## 数据异常类
+- [ ] 余额不足如何处理
+- [ ] 参数错误如何处理
+- [ ] 数据不一致如何处理
+- [ ] 数据为空时展示什么
+- [ ] 订单量为 0 时展示什么
+
+## 第三方异常类
+- [ ] 回调失败如何重试
+- [ ] 状态不一致如何同步
+- [ ] 主动查询机制
+
+## 绕过场景类
+- [ ] 站外支付如何识别
+- [ ] 跳过中间环节如何处理
+- [ ] 直接 URL 访问被拦截
+
+## 并发场景类
+- [ ] 同一资源被两人同时操作
+- [ ] 回刷任务重复执行（幂等）
+- [ ] 配置修改与任务执行并发