@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-quality/skills/workflow-complete-milestone/references/milestone-archive.md

@@ -0,0 +1,123 @@
+# Milestone Archive Template
+
+This template is used by the complete-milestone workflow to create archive files in `.planning/milestones/`.
+
+---
+
+## File Template
+
+# Milestone v{{VERSION}}: {{MILESTONE_NAME}}
+
+**Status:** ✅ SHIPPED {{DATE}}
+**Phases:** {{PHASE_START}}-{{PHASE_END}}
+**Total Plans:** {{TOTAL_PLANS}}
+
+## Overview
+
+{{MILESTONE_DESCRIPTION}}
+
+## Phases
+
+{{PHASES_SECTION}}
+
+[For each phase in this milestone, include:]
+
+### Phase {{PHASE_NUM}}: {{PHASE_NAME}}
+
+**Goal**: {{PHASE_GOAL}}
+**Depends on**: {{DEPENDS_ON}}
+**Plans**: {{PLAN_COUNT}} plans
+
+Plans:
+
+- [x] {{PHASE}}-01: {{PLAN_DESCRIPTION}}
+- [x] {{PHASE}}-02: {{PLAN_DESCRIPTION}}
+      [... all plans ...]
+
+**Details:**
+{{PHASE_DETAILS_FROM_ROADMAP}}
+
+**For decimal phases, include (INSERTED) marker:**
+
+### Phase 2.1: Critical Security Patch (INSERTED)
+
+**Goal**: Fix authentication bypass vulnerability
+**Depends on**: Phase 2
+**Plans**: 1 plan
+
+Plans:
+
+- [x] 02.1-01: Patch auth vulnerability
+
+**Details:**
+{{PHASE_DETAILS_FROM_ROADMAP}}
+
+---
+
+## Milestone Summary
+
+**Decimal Phases:**
+
+- Phase 2.1: Critical Security Patch (inserted after Phase 2 for urgent fix)
+- Phase 5.1: Performance Hotfix (inserted after Phase 5 for production issue)
+
+**Key Decisions:**
+{{DECISIONS_FROM_PROJECT_STATE}}
+[Example:]
+
+- Decision: Use ROADMAP.md split (Rationale: Constant context cost)
+- Decision: Decimal phase numbering (Rationale: Clear insertion semantics)
+
+**Issues Resolved:**
+{{ISSUES_RESOLVED_DURING_MILESTONE}}
+[Example:]
+
+- Fixed context overflow at 100+ phases
+- Resolved phase insertion confusion
+
+**Issues Deferred:**
+{{ISSUES_DEFERRED_TO_LATER}}
+[Example:]
+
+- PROJECT-STATE.md tiering (deferred until decisions > 300)
+
+**Technical Debt Incurred:**
+{{SHORTCUTS_NEEDING_FUTURE_WORK}}
+[Example:]
+
+- Some workflows still have hardcoded paths (fix in Phase 5)
+
+---
+
+_For current project status, see .planning/ROADMAP.md_
+
+---
+
+## Usage Guidelines
+
+<guidelines>
+**When to create milestone archives:**
+- After completing all phases in a milestone (v1.0, v1.1, v2.0, etc.)
+- Triggered by complete-milestone workflow
+- Before planning next milestone work
+
+**How to fill template:**
+
+- Replace {{PLACEHOLDERS}} with actual values
+- Extract phase details from ROADMAP.md
+- Document decimal phases with (INSERTED) marker
+- Include key decisions from PROJECT-STATE.md or SUMMARY files
+- List issues resolved vs deferred
+- Capture technical debt for future reference
+
+**Archive location:**
+
+- Save to `.planning/milestones/v{VERSION}-{NAME}.md`
+- Example: `.planning/milestones/v1.0-mvp.md`
+
+**After archiving:**
+
+- Update ROADMAP.md to collapse completed milestone in `<details>` tag
+- Update PROJECT.md to brownfield format with Current State section
+- Continue phase numbering in next milestone (never restart at 01)
+  </guidelines>

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

@@ -0,0 +1,126 @@
+---
+name: workflow-generate-mainflow-cases
+description: "Use after workflow-execute-phase when code is implemented and the OMP development agent must generate importable positive API/UI mainflow automation cases from planning artifacts, project specifications, navigation files, and actual code."
+---
+
+# 主流程自动化用例生成
+
+在 `execute` 完成后运行本 skill，生成当前测试聚合平台可导入的正向主流程自动化用例。只生成 `api-mainflow` 和 `ui-mainflow` 用例，不生成异常、边界、权限、安全、性能专项。
+
+## Hard Rules
+
+- MUST NOT hardcode `platform-backend` or `platform-frontend`.
+- MUST derive code roots from `.planning/navigation` and `.context/spec`.
+- MUST use `.planning/code-index/` for fine-grained entrypoint, route, component, API, call, import, and data-flow evidence when present.
+- MUST only generate `api-mainflow` and `ui-mainflow` cases.
+- MUST run `scripts/compile_dsl.py` before final output.
+- MUST run `scripts/validate_case_payloads.py` before reporting success.
+- MUST block if codebase discovery fails.
+- MUST block if generated DSL fails validation.
+
+## Workflow Position
+
+This step sits between code execution and verification. It runs after `execute` alongside `code-review`; `verify` depends on both gates:
+
+`execute -> code-review + generate-mainflow-cases -> verify-work / UAT`
+
+The workflow step id is `generate-mainflow-cases`, order `86`, and it depends on `execute`.
+
+## Required Outputs
+
+Always create or update:
+
+- `.planning/generated-cases/{feature}/source-map.md`
+- `.planning/generated-cases/{feature}/mainflow-analysis.md`
+- `.planning/generated-cases/{feature}/case-descriptions.json`
+- `.planning/generated-cases/{feature}/case-import-payloads.json`
+- `.planning/generated-cases/{feature}/validation-report.md`
+- `.planning/phases/{phase}/MAINFLOW-CASES.md`
+
+The discovery script also writes support artifact `.planning/generated-cases/{feature}/codebase-discovery.json`.
+
+## Resource Loading
+
+Read these references before generating cases:
+
+- `references/codebase-discovery.md` before scanning any source file.
+- `references/mainflow-selection.md` before deciding which flows become cases.
+- `references/intermediate-format.md` before writing `case-descriptions.json`.
+- `references/api-mainflow-rules.md` before generating API cases.
+- `references/ui-mainflow-rules.md` before generating UI cases.
+
+## Process
+
+1. Read `.planning/STATE.md` and resolve `{feature}` and `{phase}`.
+2. Run codebase discovery:
+
+   ```text
+   devflow_mainflow(action="discover", args=["--output", ".planning/generated-cases/{feature}/codebase-discovery.json"])
+   ```
+
+   Stop if it exits non-zero.
+
+3. Read planning inputs when present:
+   - `.planning/requirements/baseline.md`
+   - `.planning/features/{feature}/功能点梳理.md`
+   - `.planning/features/{feature}/UI-SPEC.md`
+   - `.planning/features/{feature}/前端技术方案.md`
+   - `.planning/features/{feature}/后端技术方案.md`
+   - `.planning/features/{feature}/变更清单.md`
+   - `.planning/features/{feature}/PROGRESS.md`
+   - `.planning/phases/{phase}/SUMMARY.md`
+
+4. Read discovery output, then read each discovered codebase's navigation and spec files. Select scan targets by codebase type:
+   - Backend: router/controller, service/usecase, schema/dto/request/response, model/entity, API entry.
+   - Frontend: router, pages/views, api/client, types/contracts, stores/hooks/components related to the feature.
+
+5. If `.planning/code-index/` exists, query symbols and relations for candidate entrypoints and mainflow paths:
+   - Backend/API: `routes_to`, `calls`, `reads`, `writes`, `config_uses`, `tested_by`.
+   - Frontend/UI: route/page/component symbols, `routes_to`, `imports`, `calls` into API clients, store/hook relations.
+   Read `evidence_path:evidence_line` before using an edge in case selection.
+6. Inspect actual code paths that are both relevant to `{feature}` and reachable from navigation/spec/code-index. Do not scan excluded historical modules.
+7. Write `source-map.md` with planning evidence, code-index evidence when used, source evidence, and selected source files for each candidate case.
+8. Write `mainflow-analysis.md` with included API/UI positive mainflows, excluded non-mainflows, assumptions, and traceability to source evidence.
+9. Write `case-descriptions.json` using the simplified format in `references/intermediate-format.md`. **Do NOT write raw DSL** — use locator strings like `"text:编辑"`, `"placeholder:请输入名称"`, `"css:.el-dialog__footer .el-button--primary"`.
+10. Compile descriptions into strict DSL:
+
+   ```text
+   devflow_mainflow(action="compile", args=[".planning/generated-cases/{feature}/case-descriptions.json", "--output", ".planning/generated-cases/{feature}/case-import-payloads.json"])
+   ```
+
+   Stop if it exits non-zero. The compiler owns all target key selection, strategy decisions, and assertion formatting.
+
+11. Validate compiled payloads:
+
+    ```text
+    devflow_mainflow(action="validate", args=[".planning/generated-cases/{feature}/case-import-payloads.json", "--discovery", ".planning/generated-cases/{feature}/codebase-discovery.json", "--output", ".planning/generated-cases/{feature}/validation-report.md"])
+    ```
+
+    Stop if it exits non-zero.
+
+11. Write `.planning/phases/{phase}/MAINFLOW-CASES.md` summarizing:
+    - Generated case count by tag.
+    - Import payload path.
+    - Validation status.
+    - Source evidence index.
+    - Any environment data needed before execution.
+
+12. Report success only after compilation and validation pass.
+
+## AI Scope
+
+AI is responsible for semantic judgment only:
+
+- Determine feature scope from `.planning`.
+- Confirm implemented behavior from actual code.
+- Identify positive API mainflows.
+- Identify positive UI mainflows.
+- Generate `case-descriptions.json` in simplified intermediate format.
+- Record source evidence for each case.
+
+AI is NOT responsible for DSL formatting. The `compile_dsl.py` script owns:
+- Target key selection (`label`, `css`, `placeholder`, etc.)
+- Strategy decisions (`structured_first` vs `ai_only`)
+- Assertion type selection and formatting
+- Auth step generation
+- Step ID assignment and dependency wiring

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/references/api-mainflow-rules.md

@@ -0,0 +1,27 @@
+# API Mainflow Rules
+
+API cases validate successful backend behavior through importable DSL.
+
+## Step Rules
+
+- Use `driver: "api"`.
+- Use HTTP method as `action`: `get`, `post`, `put`, `patch`, `delete`, `head`, or `options`.
+- Set `params.url` for every API step.
+- Put query values under `params.params`.
+- Put JSON request payloads under `params.json` or `params.body`.
+- Add success assertions for status code and key response fields where code/planning provide them.
+- Extract ids or tokens only into variables, never literal secrets.
+- Use `depends_on` to model required execution order.
+
+## Source Evidence
+
+Cite at least one planning artifact and one code artifact per case:
+
+- Planning: backend tech spec, change list, feature breakdown, or requirement baseline.
+- Code: router/controller and service/usecase, plus schema/model when they define the contract.
+
+## Positive Mainflow Boundary
+
+Allowed: create/list/detail/update/execute success flow for the current feature.
+
+Not allowed: invalid request, unauthorized access, missing resource, validation error, conflict, retry, timeout, or performance scenario.

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/references/codebase-discovery.md

@@ -0,0 +1,54 @@
+# Codebase Discovery
+
+Use discovery before reading feature source files. The goal is to make the skill portable across projects that have valid `.planning` and `.context/spec` initialization artifacts.
+
+## Required Sources
+
+Read and cross-check:
+
+- `.planning/STATE.md`
+- `.planning/navigation/INDEX.md`
+- `.context/spec/index.md`
+- `.planning/navigation/{CODEBASE}.md`
+- `.context/spec/{domain}/{CODEBASE}.md`
+
+Do not infer code roots from common directory names. Treat the navigation/spec registry as the source of truth.
+
+## Script Contract
+
+Run:
+
+```text
+devflow_mainflow(action="discover", args=["--output", ".planning/generated-cases/{feature}/codebase-discovery.json"])
+```
+
+The script must fail if:
+
+- `.planning/navigation/INDEX.md` is missing.
+- `.context/spec/index.md` is missing.
+- A registered codebase lacks a root path, navigation path, or spec path.
+- A registered root path does not exist.
+- A registered navigation/spec file does not exist.
+
+## Discovery Output
+
+Use `codebase-discovery.json` fields:
+
+- `codebases[].name`
+- `codebases[].type`
+- `codebases[].domain`
+- `codebases[].root`
+- `codebases[].navigation`
+- `codebases[].spec`
+- `codebases[].stack_key`
+- `codebases[].scan_profile`
+
+Current project discovery should resolve `BACKEND` and `FRONTEND`, but this is an output fact, not a skill rule.
+
+## Scan Range By Type
+
+Backend codebases: read navigation/spec sections or file lists that declare router/controller, service/usecase, schema/dto/request/response, model/entity, and API entry points. Prefer files mentioned in planning documents and change lists.
+
+Frontend codebases: read navigation/spec sections or file lists that declare router, pages/views, api/client, types/contracts, and stores/hooks/components related to the feature. Prefer files mentioned in planning documents and change lists.
+
+If navigation/spec uses different labels, map them semantically rather than by exact heading.

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/references/intermediate-format.md

@@ -0,0 +1,244 @@
+# Intermediate Case Description Format
+
+AI 产出的简化用例描述格式。locator 用 `"type:value"` 字符串，不直接写 DSL target。
+
+## Hard Rule: Source-Backed Terminology
+
+**All UI text in locators, step names, and descriptions MUST be exact strings extracted from source code.** Do not invent, translate, or guess.
+
+| 来源 | 可以用的 | 不可以用的 |
+|---|---|---|
+| 源码模板/JSX中的button文本 | `"text:查询"` | 自己编的 `"text:搜索"` |
+| 源码中的placeholder属性 | `"placeholder:请输入名称"` | 猜的 `"placeholder:搜索关键词"` |
+| 源码中的dialog title | `"verify:创建成功"` | 改写的 `"verify:操作成功"` |
+| 路由/菜单配置文件 | `name: "项目管理"` | `name: "项目列表页"` |
+
+**Anti-pattern**: AI 看到列表页的查询表单,自己把"查询"按钮改叫"搜索"按钮。源码写的是什么，locator 和 step name 就写什么。
+
+### List Page Pattern Recognition
+
+列表页常见两种模式，必须根据源码区分：
+
+| 模式 | 特征 | 按钮文本 | 行为 |
+|---|---|---|---|
+| **列表查询/筛选** | 输入框+按钮在表格上方,URL含 `/List` 或 `/list` | 通常为"查询"、"筛选" | 过滤当前列表,不跳转 |
+| **全局搜索** | 搜索框在header/侧边栏,触发路由跳转 | 通常为"搜索" | 跳转到搜索页 |
+
+判断依据: **看源码中按钮的实际文本**,不要自己推断。
+
+## Top-level shape
+
+```json
+{
+  "project_id": 6,
+  "name": "Case name",
+  "description": "Positive mainflow purpose",
+  "tags": ["ui-mainflow"],
+  "variables": { "base_url": "http://admin.test.example.com" },
+  "auth": { ... },
+  "steps": [ ... ]
+}
+```
+
+## Auth (optional)
+
+Only include if the case needs API login + token injection.
+
+```json
+{
+  "auth": {
+    "method": "api_login",
+    "login_url": "http://auth.test.example.com/admin/auth/login_by_id",
+    "login_body": { "userid": "${userid}", "password": "${password}" },
+    "token_path": "headers.X-Jwt-Token",
+    "app_token_url": "http://auth.test.example.com/admin/app/access",
+    "app_id": 6
+  }
+}
+```
+
+The compiler auto-generates: login API step → app token step → web inject step.
+
+## Steps
+
+### Common fields
+
+| Field | Required | Description |
+|---|---|---|
+| `name` | yes | Human-readable step name |
+| `action` | yes | See action types below |
+| `timeout_ms` | no | Default 30000 for navigation, 5000 for UI clicks, 15000 for wait/verify |
+
+### Action types
+
+#### `navigate` — open a page
+
+```json
+{
+  "name": "导航到页面",
+  "action": "navigate",
+  "url": "${base_url}/admin/page"
+}
+```
+
+Compiler output: `driver=web, action=goto`
+
+#### `click` — click a UI element
+
+```json
+{
+  "name": "点击编辑",
+  "action": "click",
+  "locator": "text:编辑",
+  "scope": "row:1"
+}
+```
+
+Compiler output: `driver=ui, action=click, strategy=structured_first`
+
+`scope` values:
+- (omit) — page-unique element, compiler adds `exact: true`
+- `"row:N"` — table row N, compiler adds CSS row selector alongside label
+- `"dialog"` — inside a dialog, compiler uses label as-is
+
+#### `fill` — fill a form input
+
+```json
+{
+  "name": "输入名称",
+  "action": "fill",
+  "locator": "placeholder:请输入名称",
+  "value": "填写的内容"
+}
+```
+
+Compiler output: `driver=ui, action=fill, strategy=structured_first`
+
+#### `select` / `hover` — select option or hover
+
+```json
+{
+  "name": "选择类型",
+  "action": "select",
+  "locator": "text:类型A",
+  "value": "option_value"
+}
+```
+
+#### `verify` — verify success/result
+
+```json
+{
+  "name": "验证操作成功",
+  "action": "verify",
+  "locator": "text:操作成功",
+  "expect": "text:操作成功",
+  "timeout_ms": 15000
+}
+```
+
+Compiler output: `driver=ui, action=act, strategy=ai_only`, with auto-generated prompt.
+
+`expect` values:
+- `"text:xxx"` → check that text "xxx" appears on screen
+- `"dialog_visible"` → check dialog is open
+- `"dialog_closed"` → check dialog closed
+- `"url_contains:xxx"` → check URL contains "xxx"
+
+#### API steps
+
+```json
+{
+  "name": "创建记录",
+  "action": "post",
+  "params": {
+    "url": "${base_url}/api/resource",
+    "json": { "name": "test" }
+  },
+  "assertions": [
+    { "type": "status_code", "expected": 200 },
+    { "type": "json_path_exists", "path": "body.data.id" }
+  ],
+  "extract_vars": {
+    "resource_id": { "path": "body.data.id", "source": "jsonpath" }
+  }
+}
+```
+
+Compiler output: `driver=api, action=post`
+
+#### `wait` — wait for page/element
+
+```json
+{
+  "name": "等待加载",
+  "action": "wait",
+  "wait_for": "load",
+  "timeout_ms": 5000
+}
+```
+
+Compiler output: `driver=web, action=wait`
+
+#### `inject_token` — inject auth token
+
+Rarely needed directly — prefer using `auth` config. Only use if auth pattern is non-standard.
+
+```json
+{
+  "name": "注入Token",
+  "action": "inject_token",
+  "script": "localStorage.setItem('token', '${jwt_token}')"
+}
+```
+
+## Locator Hard Rules — Zero Tolerance for Fabrication
+
+**CSS 选择器和 XPath 是精确匹配器，必须来自源码实际存在的 class/结构。禁止 AI 编造任何 CSS class 名或 XPath 表达式。**
+
+编译器检测到以下特征会直接拒绝：
+- CSS 含 `%`（编造的 utility class，如 `.w-100%`）
+- 纯容器类（`.el-form-item`、`.el-form-item__content`）— 匹配所有字段而非特指
+- 随机生成的 class 名模式
+- 长度 < 10 字符的裸 class
+
+### fill 动作的硬决策链
+
+fill 动作按此顺序选择 locator，禁止跳过：
+
+1. 字段有 placeholder？ → `placeholder:xxx`
+2. 没有？字段前有 label 文本？ → `near:label文本`
+3. 都不行？ → `ai_only`（禁止编 CSS）
+
+### click 动作的决策链
+
+1. 页面唯一文本（按钮/菜单/tab） → `text:xxx`
+2. 表格行操作（每行重复） → `text:编辑` + `scope: "row:N"`
+3. ARIA 属性完整 → `role:button:确定`
+4. 对话框内确定/取消 → `css:.el-dialog__footer .el-button--primary`（Element Plus 标准结构，非编造）
+5. 源码中有明确的特定 class（须在 source-map.md 注明出处） → `css:xxx`
+6. 都不行 → `ai_only`
+
+## Locator Format Reference
+
+| Format | Example | Compiler produces |
+|---|---|---|
+| `text:<text>` | `"text:新增项目库"` | `{"label": "新增项目库", "exact": true}` |
+| `placeholder:<text>` | `"placeholder:请输入名称"` | `{"placeholder": "请输入名称"}` |
+| `near:<text>` | `"near:项目介绍"` | `{"near_text": "项目介绍"}` |
+| `css:<selector>` | `"css:.el-dialog__footer .el-button--primary"` | `{"css": ".el-dialog__footer ..."}` |
+| `role:<role>:<name>` | `"role:button:确定"` | `{"role": "button", "name": "确定"}` |
+| `xpath:<expr>` | `"xpath://button[text()='确定']"` | `{"xpath": "//button[text()='确定']"}` |
+
+### Anti-patterns
+
+```
+// WRONG: 编造的 CSS class
+"locator": "css:.w-100% .el-form-item__content"
+
+// WRONG: 纯容器类，不特指字段
+"locator": "css:.el-form-item__content"
+
+// CORRECT: fill 用 near_text
+"locator": "near:项目介绍"
+```

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

@@ -0,0 +1,36 @@
+# Mainflow Selection
+
+Generate only positive API/UI mainflows that represent normal user or system success paths.
+
+## Include
+
+- P0/P1 positive scenarios explicitly implemented by the current feature.
+- API flows that call public API entries in successful order with valid request data.
+- UI flows that cover the primary happy path visible to users.
+- UI flows may include API setup steps if needed to create prerequisites.
+- Assertions that confirm success status, expected response fields, visible UI state, or navigation result.
+
+## Exclude
+
+- Exceptions, error handling, invalid input, missing data, retry, timeout, conflict, and rollback cases.
+- Boundary value tests.
+- Permission/role/security tests.
+- Performance, load, concurrency, soak, and stability tests.
+- Migration-only checks and internal refactor checks.
+- Flows not implemented in actual code, even if mentioned in planning.
+- Historical modules excluded by navigation.
+
+## Selection Method
+
+1. Use planning documents to identify intended feature scope and FP/BR/CR IDs.
+2. Use code to confirm implemented endpoints, UI routes, components, and API client calls.
+3. Keep a case only when planning intent and code reality both support it.
+4. Prefer fewer complete mainflow cases over many shallow fragments.
+5. Record every inclusion and exclusion in `mainflow-analysis.md`.
+
+## Case Granularity
+
+- One API case should cover one coherent backend success path.
+- One UI case should cover one coherent user journey.
+- Do not split a single user journey into multiple cases unless the platform requires independent setup.
+- Do not combine unrelated features into one case.