@guanlin4924/devflow-pi 0.1.93 → 0.1.95

package/plugins/devflow-quality/runtime/playwright/runtime-manifest.json

@@ -0,0 +1,11 @@
+{
+  "schema_version": 1,
+  "runtime_version": "0.1.0",
+  "playwright_version": "1.63.0",
+  "files": {
+    "runner.spec.mjs": "5612cde9ddef5a203829d86ab45788d65cbe83891ff7dbb73c308aa9345ead83",
+    "playwright.config.mjs": "301c0b97e229f83e6934994718b11b93a1da5d46ec606cfd11a8292e9d622b02",
+    "reporter.mjs": "5c91d68c50a93603f583cf82345d427bcd9ce9a7cfb78fd6d0989abddbd55275",
+    "devflow-test-dsl-v1.schema.json": "21ce608adcaf60ac138b532b7731f3b74c3e2749cba26dfeb12fc12ce0b6e5f3"
+  }
+}

package/plugins/devflow-quality/skills/code-review/SKILL.md

@@ -15,11 +15,11 @@ description: "Use when code needs review for project conventions, spec complianc
 4. 若需修复后复审，在下一轮 task 中携带上一轮 `chain_id`，最多三轮。第三轮仍有 P0 时停止当前任务；事实不足时停止并请求人工确认。每轮重新验证源码、契约和证据版本，不复用旧结论。
 5. 主 Agent 向用户交付门禁裁决、证据链、开放 finding 与下一步动作。本文后续的规范扫描和检查清单仍用于审查内容，但其“输出 Markdown”要求仅适用于独立调用本技能，不覆盖正式工作流协议。
 
-逐层对照 `.context/spec/` 规范文档，检查目标代码的合规性，输出可操作的问题清单。若项目存在 `.context/spec/index.md`，先按索引匹配 stack spec 和 codebase spec，再加载具体层级规范。
+逐层对照 `.devflow/context/spec/` 规范文档，检查目标代码的合规性，输出可操作的问题清单。若项目存在 `.devflow/context/spec/index.md`，先按索引匹配 stack spec 和 codebase spec，再加载具体层级规范。
 
 ## 核心原则
 
-1. **规范是唯一标准** — 只对照 `.context/spec/` 中的规范文档，不参考其他已有代码；代码推断规则必须低于显式规范和 codebase spec
+1. **规范是唯一标准** — 只对照 `.devflow/context/spec/` 中的规范文档，不参考其他已有代码；代码推断规则必须低于显式规范和 codebase spec
 2. **文件级全量扫描** — 扫描目标文件的每一行，不只看"最近改动的部分"
 3. **逐条不跳过** — 规范文档中的每一条规则都要检查，包括"看起来无关"的细节。**禁止主观过滤**：不能因为"这个 VO 字段很简单"、"只有一个字段"、"直接传字符串"等主观判断而跳过检查项，规范就是规范，简单的代码同样要逐条对照
 4. **加法和减法都查** — 既查"缺了什么该有的"，也查"多了什么不该有的"（未使用方法/字段/import）
@@ -31,7 +31,7 @@ description: "Use when code needs review for project conventions, spec complianc
 **当 code-review 作为 feature-development 工作流的独立 `code-review` step 被调用时必须执行。** 独立调用 code-review（如"帮我 review 一下 XX 模块"）时，若提供 phase number 则尝试关联变更清单，否则跳过此步。
 
 1. **定位变更清单**：
-   - 若传入 phase number：从 phase 目录的 CONTEXT.md 推断功能名，查找 `.planning/features/{功能名}/变更清单.md`
+   - 若传入 phase number：从 phase 目录的 CONTEXT.md 推断功能名，查找 `.devflow/planning/features/{功能名}/变更清单.md`
    - 若直接调用但用户提供了变更清单路径：使用用户指定路径
    - 若找不到变更清单：跳过此步，在输出 REVIEW.md 中标注 "无变更清单，跳过完成标准验证"
 
@@ -114,12 +114,12 @@ seam 标注: "只改 OrderWorkflow.process()"
 ### 第二步：加载规范（渐进式）
 
 **必读**（每次审查都要读）：
-1. `.planning/rules/INDEX.md`（如存在）— 找到项目规则入口
-2. `.context/spec/index.md`（如存在）— 匹配目标文件所在 codebase 的 stack spec 和 codebase spec
-3. 命中的 `.context/spec/stacks/{stack_key}.md` — 技术栈通用规范
-4. 命中的 `.context/spec/backend|frontend/{codebase}.md` — 项目实例规范
-5. `.planning/code-index/`（如存在）— 用于调用方、被调用方、导入、读写资源、测试覆盖等关系事实定位
-6. 兼容旧规范：`.context/spec/backend/index.md` 和 `.context/spec/backend/go.md`（如存在）
+1. `.devflow/planning/rules/INDEX.md`（如存在）— 找到项目规则入口
+2. `.devflow/context/spec/index.md`（如存在）— 匹配目标文件所在 codebase 的 stack spec 和 codebase spec
+3. 命中的 `.devflow/context/spec/stacks/{stack_key}.md` — 技术栈通用规范
+4. 命中的 `.devflow/context/spec/backend|frontend/{codebase}.md` — 项目实例规范
+5. `.devflow/planning/code-index/`（如存在）— 用于调用方、被调用方、导入、读写资源、测试覆盖等关系事实定位
+6. 兼容旧规范：`.devflow/context/spec/backend/index.md` 和 `.devflow/context/spec/backend/go.md`（如存在）
 
 **按层级按需加载**（只读涉及的层级，详见 `references/spec-checklist.md`）：
 - Handler 层 → 读 `handler.md`
@@ -130,7 +130,7 @@ seam 标注: "只改 OrderWorkflow.process()"
 - 有分页 → 读 `pagination.md`
 
 **经验教训**（目录存在时读取）：
-- `.context/lessons/README.md`（如存在）— 项目积累的踩坑经验；不存在时跳过，不阻塞审查
+- `.devflow/context/lessons/README.md`（如存在）— 项目积累的踩坑经验；不存在时跳过，不阻塞审查
 
 ### 第三步：逐层执行审查
 
@@ -150,7 +150,7 @@ seam 标注: "只改 OrderWorkflow.process()"
 **⛔ Gate 合规检查：** 审查输出中，每个涉及源码的结论必须附带 code-index 符号引用（格式：`[符号名 @ path:line]`）。若审查全程未出现 code-index 查询操作，或输出中的源码引用无 code-index 依据，则在问题清单最上方追加：
 
 ```
-⛔ SOURCE-READ GATE VIOLATION — 本次审查未走 .planning/code-index/ gate。
+⛔ SOURCE-READ GATE VIOLATION — 本次审查未走 .devflow/planning/code-index/ gate。
 审查结论降级为"未经索引验证"，需重新执行。
 ```
 
@@ -244,7 +244,7 @@ seam 标注: "只改 OrderWorkflow.process()"
 ```markdown
 ## 完成标准验证
 
-> **来源**：`.planning/features/{功能名}/变更清单.md`
+> **来源**：`.devflow/planning/features/{功能名}/变更清单.md`
 > **格式**：checkbox（N 条）/ legacy（M 条）
 > **总结**：{passed}/{total} 通过，{failed} 未通过，{unverifiable} 待人工，{skipped} 跳过
 

package/plugins/devflow-quality/skills/code-review/references/spec-checklist.md

@@ -4,7 +4,7 @@
 
 ## 规范文件路径
 
-所有规范文件位于 `.context/spec/backend/` 目录下。
+所有规范文件位于 `.devflow/context/spec/backend/` 目录下。
 
 ## 加载矩阵
 

package/plugins/devflow-quality/skills/workflow-acceptance-test-design/SKILL.md

@@ -13,22 +13,22 @@ description: "Use after integration verification and before change planning to d
 
 1. 先调用 `devflow_contract(action="status")` 检查当前会话是否有 active contract；
 2. 未激活时调用 `devflow_contract(action="activate", feature="<feature>", step="acceptance-test-design")` 合成并激活（planning / waiting-user / awaiting-approval，或 Runtime 已触发当前步骤的 executing 回合均可；Core 校验 STATE 当前 feature/step 与图谱 revision 后由用户确认）；
-3. 会话中断后 contract 由 runtime 在 `session_start` 时从 `.planning/contracts/{feature}/EC-*.json` 自动恢复；恢复时校验 state/graph revision，推进后自动失效，需重新合成。
+3. 会话中断后 contract 由 runtime 在 `session_start` 时从 `.devflow/planning/contracts/{feature}/EC-*.json` 自动恢复；恢复时校验 state/graph revision，推进后自动失效，需重新合成。
 
 ## 输入
 
 按顺序读取：
 
 1. `devflow_requirement_graph(action="inspect")` 的已确认 `REQ/BR/BC/AC` 节点与当前 revision；
-2. `.planning/features/{feature}/integration-report.md`、API 契约、UI 方案、前后端技术方案；
+2. `.devflow/planning/features/{feature}/integration-report.md`、API 契约、UI 方案、前后端技术方案；
 3. 当前图谱中的 `RISK/WSH/WLC/DECISION` 节点；
-4. `.planning/toolchain.md`、`.planning/execution-contract.md` 和项目测试能力。
+4. `.devflow/planning/toolchain.md`、`.devflow/planning/execution-contract.md` 和项目测试能力。
 
 若需求、契约或架构事实不足以写出可观察 oracle，记录缺口并回流到上游；不得用实现猜测补全。
 
 ## 生成规则
 
-先调用 `devflow_api_test_matrix(action="compile", feature="...")`（无 API 时也会写 no-op 测试资产），检查 `.planning/features/{feature}/完整API验收测试用例.md` 中的契约缺口；存在 `API-*` 时通过后调用 `devflow_api_test_matrix(action="import", feature="...")`。Core 会一次性生成并导入全部 API `TC-*`：
+先调用 `devflow_api_test_matrix(action="compile", feature="...")`（无 API 时也会写 no-op 测试资产），检查 `.devflow/planning/features/{feature}/完整API验收测试用例.md` 中的契约缺口；存在 `API-*` 时通过后调用 `devflow_api_test_matrix(action="import", feature="...")`。Core 会一次性生成并导入全部 API `TC-*`：
 
 - 每个字段的缺失、`null`、错误类型、最小/最大（长度、数值、数组项）、超长、非法格式/模式、非法枚举；
 - 仅由有效等价类构成的 pairwise 组合（负向值一项一测，避免错误码歧义）；
@@ -43,6 +43,7 @@ description: "Use after integration verification and before change planning to d
   "acceptance_refs": ["AC-0001"],
   "requirement_refs": ["REQ-0001", "BR-0001"],
   "test_type": "api|page|permission|boundary|resilience|migration|performance",
+  "execution_surface": "http|ui|api_flow|project_test",
   "target": "外部可观察的 API、页面或运行边界",
   "preconditions": ["身份、数据和环境前置条件"],
   "steps": ["测试操作"],
@@ -52,6 +53,8 @@ description: "Use after integration verification and before change planning to d
 }
 ```
 
+- `execution_surface` 必须显式填写：单个 Core HTTP 请求且断言来自 `execution` 用 `http`；真实页面交互用 `ui`；受限 DSL 中的多步骤 API 或 UI/API 组合用 `api_flow`；项目自有测试命令、权限、边界、韧性、迁移和性能专项用 `project_test`。`page` 必须对应 `ui`，带 `execution.protocol: http` 的 Core API TC 必须对应 `http`；新冻结 TC 缺失或冲突会被 CP-3 拒绝。
+- `automated` 的 `ui` / `api_flow` TC 在 `run-acceptance-tests` 绑定阶段必须有 v1 DSL（`workflow-generate-mainflow-cases` 生成，`covers` 逐条映射 `preconditions[i]`、`steps[i]` 和 `oracle`）并经用户批准 `execution_plan`，否则只会 blocked。因此每个前置条件和步骤要写成可单独映射的原子条目，oracle 要写成确定性的可观察结果（具体文案、URL、响应字段）；需要纯视觉判断、缺少稳定 locator 或无法准备/隔离数据的场景，现在就标 `manual` 或 `blocked`，不要标 `automated`。
 - `manual` 额外写 `manual_reason` 和 `owner`；`blocked` 额外写 `blocked_by` 和 `owner`。
 - `replay`：可用稳定步骤再次触发，必须写 `replay_scope`（`component|page|api|integration`）。页面优先拆到组件、页面、接口或集成边界，不要求 AI 在真实环境盲目重试。
 - `causal`：用于已由 HAR、控制台、DOM 快照、服务日志或请求链路证明首个偏差、但暂不能稳定重放的缺陷。必须写 `causal_evidence_refs`（已有 `SRC-*` / `CODE-*`）和 `first_divergence`；后续执行绑定还必须提供实际证据文件，Core 会哈希留档。没有这些证据不能称为“已证实”。
@@ -62,13 +65,13 @@ description: "Use after integration verification and before change planning to d
 
 ## 输出
 
-写 `.planning/features/{feature}/验收测试设计.md` 作为派生视图，包含：TC 覆盖矩阵、自动/人工/阻塞数量、每项专项义务的 TC/环境前提和当前图谱 revision。写对应 `.meta.json`，其 revision/fingerprint 必须来自 Core 的 `tests.json` 视图。
+写 `.devflow/planning/features/{feature}/验收测试设计.md` 作为派生视图，包含：TC 覆盖矩阵、自动/人工/阻塞数量、每项专项义务的 TC/环境前提和当前图谱 revision。写对应 `.meta.json`，其 revision/fingerprint 必须来自 Core 的 `tests.json` 视图。
 
 API 完整测试资产由 Core 额外写入：
 
-- `.planning/requirements/{feature}/api-test-matrix.json`：机器可读的请求、预期和派生义务；
-- `.planning/features/{feature}/完整API验收测试用例.md`：可审查的人类视图；
-- `.planning/features/{feature}/api-acceptance-bindings.template.json`：导入后的 TC 与 HTTP 执行绑定模板。
+- `.devflow/planning/requirements/{feature}/api-test-matrix.json`：机器可读的请求、预期和派生义务；
+- `.devflow/planning/features/{feature}/完整API验收测试用例.md`：可审查的人类视图；
+- `.devflow/planning/features/{feature}/api-acceptance-bindings.template.json`：导入后的 TC 与 HTTP 执行绑定模板。
 
 运行 `devflow_requirement_graph(action="validate")` 和 machine evidence。通过后交给 `workflow-change-plan` 绑定实现任务。
 

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

@@ -14,17 +14,17 @@ description: "根据功能点梳理和需求基线生成检查点树形态的测
 
 必须先读取 `legacy/SKILL.md`，再按其中引用的相对 `references/`、`assets/` 规则生成：
 
-`.planning/features/{feature}/测试指导书.md`
+`.devflow/planning/features/{feature}/测试指导书.md`
 
 当前 Devflow 输入路径映射如下（旧版 Skill 的 WORKSPACE_ROOT 逻辑已由适配器显式映射）：
 
-- `.planning/requirements/baseline.md`
-- `.planning/features/{feature}/功能点梳理.md`
-- `.planning/PROJECT.md`
-- `.planning/navigation/INDEX.md`
+- `.devflow/planning/requirements/baseline.md`
+- `.devflow/planning/features/{feature}/功能点梳理.md`
+- `.devflow/planning/PROJECT.md`
+- `.devflow/planning/navigation/INDEX.md`
 
 旧版 Skill 中的旧目录和外部 PRD URL 约定不能直接写入项目；以本适配器列出的
-`.planning/` 路径为准。若旧版资源要求读取不存在的文档，必须在“待确认/缺少内容”分支记录，不得伪造文件或事实。
+`.devflow/planning/` 路径为准。若旧版资源要求读取不存在的文档，必须在“待确认/缺少内容”分支记录，不得伪造文件或事实。
 
 该步骤只生成检查点树文档，不生成或修改 Core 所有的 `tests.json`、`api-test-matrix.json`、需求图谱和验收测试冻结事实。结构化 `TC-*` 测试仍由后续 `workflow-acceptance-test-design` 负责。
 

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

@@ -5,11 +5,11 @@ argument-hint: "<功能名> [@PRD文档.md 或 语雀URL] [--auto]"
 user-invocable: true
 pattern: generator
 inputs:
-  - ".planning/features/{feature}/功能点梳理.md"
-  - ".planning/requirements/baseline.md"
-  - ".planning/PROJECT.md"
+  - ".devflow/planning/features/{feature}/功能点梳理.md"
+  - ".devflow/planning/requirements/baseline.md"
+  - ".devflow/planning/PROJECT.md"
   - "可选 PRD 原文（仅在当前步骤明确提供时读取）"
-output: ".planning/features/{feature}/测试指导书.md"
+output: ".devflow/planning/features/{feature}/测试指导书.md"
 allowed-tools:
   - Read
   - Write
@@ -20,7 +20,7 @@ allowed-tools:
 
 # 检查点树生成 Skill
 
-> Devflow 适配说明：本文件随插件分发，由上层适配器调用。项目事实统一位于 `.planning/`；执行时以本文件的 Devflow 路径和适配器传入的输入为准，不解析旧版的 `_shared/` 或机器本地路径。
+> Devflow 适配说明：本文件随插件分发，由上层适配器调用。项目事实统一位于 `.devflow/planning/`；执行时以本文件的 Devflow 路径和适配器传入的输入为准，不解析旧版的 `_shared/` 或机器本地路径。
 
 This skill consumes 需求(PRD/baseline/功能点梳理) and creates a **检查点树**(checkpoint tree)——每个可测点展平成树的叶子检查点(一句话,可勾可数),**不是**用例字段块形态。Do not re-discuss requirements or generate technical plans.
 
@@ -32,21 +32,21 @@ This skill consumes 需求(PRD/baseline/功能点梳理) and creates a **检查
 Devflow 由 Runtime 传入当前项目根目录和 feature，不再解析旧版 `WORKSPACE_ROOT` 参数。
 
 路径约定：
-- **共享文件**: `.planning/` — PROJECT.md, STATE.md, navigation/
-- **功能文件**: `.planning/features/{feature}/` — baseline.md, 功能点梳理.md, 测试指导书.md, etc.
+- **共享文件**: `.devflow/planning/` — PROJECT.md, STATE.md, navigation/
+- **功能文件**: `.devflow/planning/features/{feature}/` — baseline.md, 功能点梳理.md, 测试指导书.md, etc.
 </workspace_config>
 
 ## Outputs
 
 Always create or update:
 
-- `.planning/features/{feature}/测试指导书.md`（**检查点树形态**,非用例字段块形态。供 change-xmind 转 xmind）
+- `.devflow/planning/features/{feature}/测试指导书.md`（**检查点树形态**,非用例字段块形态。供 change-xmind 转 xmind）
 
 > 本 skill 产出**检查点树**:每个可测点是树的一句话叶子,按 `测试视角层→功能模块→子模块/组件→状态/维度分叉→条件→叶子` 组织,**标题纯语义名(无 FP/章节号)**。**不产**用例字段块形态(无 优先级/关联/前置/步骤/预期 块)。
 
 ## Argument Handling
 
-- `<功能名>`: 由 Devflow 当前 feature 提供，用于定位 `.planning/features/{feature}/` 和输出路径。
+- `<功能名>`: 由 Devflow 当前 feature 提供，用于定位 `.devflow/planning/features/{feature}/` 和输出路径。
 - `@PRD文档.md` 或 `语雀URL`: 可选,PRD 原文(feature-breakdown 缺失时作为可测点源头,有则始终读作覆盖核对基准)。
 - `--auto`: do not ask for supplementary information; mark gaps as `待确认` 进 PT-xxx 分支。
 
@@ -83,9 +83,9 @@ Load bundled resources only when needed:
 
 源头优先级(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 用)。
+1. Read `.devflow/planning/features/{feature}/功能点梳理.md` — 首选(字段级三维叶子,可测点素材)。
+2. Read `.devflow/planning/requirements/baseline.md` — FP/BR/BC/CR 清单 + 澄清过的规则。
+3. Read `.devflow/planning/PROJECT.md` — 项目上下文 + 代码路径(Phase 1.5 用)。
 4. **Read PRD 原文**(语雀 URL 或 `@文件.md`)— 始终读,作为覆盖核对的基准。feature-breakdown/baseline 缺失时,PRD 是可测点的唯一源头。
 5. 若 feature-breakdown 和 baseline 都缺失且无 PRD → 报错,要求用户提供需求来源。
 
@@ -96,7 +96,7 @@ This phase runs ONLY when PROJECT.md "Project Locations" table contains at least
 ### 1.5.1 Load Navigation Files
 
 If code paths exist:
-1. Read `.planning/navigation/INDEX.md`.
+1. Read `.devflow/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.
@@ -264,7 +264,7 @@ Consolidate findings into an internal "Code Context Summary" (NOT written to dis
 
 ## Phase 5 — 输出检查点树
 
-加载 `assets/output-template.md`。按其层级约定写 `.planning/features/{feature}/测试指导书.md`(文件名保留,内容是检查点树形态):
+加载 `assets/output-template.md`。按其层级约定写 `.devflow/planning/features/{feature}/测试指导书.md`(文件名保留,内容是检查点树形态):
 
 1. 来源信息
 2. 检查点树(Phase 3-4 组织的 **测试视角层→功能模块→子模块/组件→状态/维度分叉→条件→叶子** 缩进结构,标题纯语义名)

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

@@ -1,127 +1,140 @@
 ---
 name: workflow-generate-mainflow-cases
-description: "Use after workflow-execute-phase to bind frozen API/page TC acceptance intent to importable positive mainflow automation cases."
+description: "Use after code review, as the binding-phase prerequisite of run-acceptance-tests, to compile one deterministic devflow-test-dsl/v1 file per frozen automated ui/api_flow TC, validate the whole generated-cases directory, get an independent AI review, and propose execution_plan approvals for the user."
 ---
 
-# 主流程自动化用例生成
+# 主流程自动化用例生成（Playwright DSL）
 
-在 `execute` 完成后运行本 skill，生成当前测试聚合平台可导入的正向主流程自动化用例。只生成 `api-mainflow` 和 `ui-mainflow` 用例，不生成异常、边界、权限、安全、性能专项。
+为冻结套件中 `automation_mode: automated` 且 `execution_surface` 为 `ui` 或 `api_flow` 的正向主流程 TC 生成确定性的 `devflow-test-dsl/v1`，每个 TC 一个文件，交给 Devflow Playwright Runtime 执行。**这是 `run-acceptance-tests` 的真实前置条件**：没有 DSL 并经用户批准 `execution_plan` 的自动化 ui/api_flow TC 只会 `blocked(dsl_not_approved)`，不能进入收口。不生成异常、边界、权限、安全、性能专项；这些 TC 按 `run-acceptance-tests` 的降级规则处理。
 
 ## 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 read the frozen `.planning/requirements/{feature}/tests.json` before selecting case scope. Only frozen positive `TC-*` with `test_type: api` or `page` may produce mainflow cases. Core-generated API TC carrying `execution.expect.error_code` is a negative/exception case and is excluded here; it is executed by `run-acceptance-tests`.
-- MUST NOT read `SUMMARY.md`, delivery self-reports, or diffs to decide what to test. Current code is allowed only to bind an already frozen TC to an entrypoint, selector, request, or runner adapter.
-- MUST run `scripts/compile_dsl.py` before final output.
-- MUST run `scripts/validate_case_payloads.py` before reporting success.
+- MUST derive code roots from `.devflow/planning/navigation` and `.devflow/context/spec`.
+- MUST use `.devflow/planning/code-index/` for fine-grained entrypoint, route, component, API, call, import, and data-flow evidence when present.
+- MUST read the frozen `.devflow/planning/requirements/{feature}/tests.json` before selecting scope. Only frozen, `confirmed`, `automation_mode: automated` TCs whose `execution_surface` is `ui` or `api_flow` get a DSL (legacy `page` TCs derive to `ui`). `http` TCs (including Core-generated API TCs with `execution.expect.error_code`) and `project_test` TCs are executed by their own adapters, not here.
+- MUST NOT read `SUMMARY.md`, delivery self-reports, or diffs to decide what to test. Current code is allowed only to bind an already frozen TC to an entrypoint, `data-testid`/locator, request path, or test data; it must never change the TC's steps or oracle.
+- MUST NOT hand-write or hand-edit `TC-xxxx.json`. Write `case-descriptions.json` and run `compile_dsl.py`; the compiler owns `tc_sha256`, target/driver generation, and hard rejections (`ai_only`, Midscene, xpath, scripts, token injection, fixed waits).
+- MUST run `compile_dsl.py`, then `validate_case_payloads.py` on the whole `generated-cases/{feature}` directory, before reporting success. Block if either exits non-zero.
 - MUST block if codebase discovery fails.
-- MUST block if generated DSL fails validation.
+- MUST get an independent AI review of every DSL against its TC oracle (advisory) before proposing approvals. The reviewer must not be the agent that wrote the descriptions.
+- MUST propose one `execution_plan` approval per automated TC with `devflow_approval`; only the user can approve it, in `/devflow` → “待审批”. The agent cannot confirm, must not write approval records, and must not treat an unapproved DSL as accepted.
+- MUST NOT create `case-import-payloads.json`. That name belongs only to the explicit legacy TestAgent export and is never a Runtime DSL artifact (see Legacy export).
 
 ## Workflow Position
 
-This step sits between code execution and frozen acceptance execution. It runs after `execute` alongside `code-review`; `run-acceptance-tests` consumes both gates:
+This skill is not a workflow step and must not appear in `pending_steps` or participate in main-chain ordering. It runs inside the binding phase of `run-acceptance-tests`:
 
-`execute -> code-review + generate-mainflow-cases -> run-acceptance-tests -> release-closeout`
+`execute -> code-review -> [human acceptance] -> generate DSL (this skill) -> bind + user approves execution plans -> run-acceptance-tests -> release closeout`
 
-The workflow step id is `generate-mainflow-cases`, order `86`, and it depends on `execute`.
+Before running, verify that the current feature's `code-review` is completed and the frozen TC suite is fresh (`devflow_acceptance_tests(feature)`). A generation, validation, or approval failure means the affected TCs cannot run as `devflow_playwright`; report it and either fix it or downgrade the TC (`manual` with a `mode_override` approval, or `blocked` with owner/reason). It never mutates workflow state itself.
 
 ## Required Outputs
 
-Always create or update:
+Always create or update, under `.devflow/planning/generated-cases/{feature}/`:
 
-- `.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`
+- `source-map.md` — frozen TC ID, planning evidence, code-index evidence, source files, and the source of every non-testid locator.
+- `mainflow-analysis.md` — included/excluded TCs with reasons (including TCs that need downgrade), assumptions, traceability.
+- `case-descriptions.json` — the AI-written input (`references/intermediate-format.md`).
+- `TC-xxxx.json` — one v1 DSL per automated ui/api_flow TC, written by `compile_dsl.py` only.
+- `validation-report.md` — output of the directory validation.
+- `ai-review.md` — the independent review findings per TC (advisory).
 
-The discovery script also writes support artifact `.planning/generated-cases/{feature}/codebase-discovery.json`.
+Also `.devflow/planning/phases/{phase}/MAINFLOW-CASES.md` (summary) and support artifact `codebase-discovery.json` (written by the discovery script).
+
+`case-import-payloads.json` is **not** an output of this skill.
 
 ## 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.
+- `references/mainflow-selection.md` before deciding which TCs become DSL.
+- `references/intermediate-format.md` before writing `case-descriptions.json` (the exact accepted format).
+- `references/project-dsl-contract.md` for the v1 DSL shape, `covers`, and the approval/hash rules.
+- `references/api-mainflow-rules.md` before generating `api_flow` cases.
+- `references/ui-mainflow-rules.md` before generating `ui` cases.
 
 ## Process
 
-1. Read `.planning/STATE.md` and resolve `{feature}` and `{phase}`.
+1. Read `.devflow/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"])
+   devflow_mainflow(action="discover", args=["--output", ".devflow/planning/generated-cases/{feature}/codebase-discovery.json"])
    ```
 
    Stop if it exits non-zero.
 
-3. Read the frozen TC suite first. Record the source `TC-*` for every selected mainflow case; a missing or stale source TC is a blocker. Then 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`
+3. Read the frozen TC suite first and list every `automated` TC whose surface is `ui` or `api_flow`. Record the source `TC-*` for each; a missing or stale TC is a blocker. Then read planning inputs when present:
+   - `.devflow/planning/requirements/baseline.md`
+   - `.devflow/planning/features/{feature}/功能点梳理.md`
+   - `.devflow/planning/features/{feature}/UI-SPEC.md`
+   - `.devflow/planning/features/{feature}/前端技术方案.md`
+   - `.devflow/planning/features/{feature}/后端技术方案.md`
+   - `.devflow/planning/features/{feature}/变更清单.md`
+   - `.devflow/planning/features/{feature}/PROGRESS.md`
 
-4. Read discovery output, then read each discovered codebase's navigation and spec files. Select scan targets by codebase type:
+4. Read discovery output, then 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:
+5. If `.devflow/planning/code-index/` exists, query symbols and relations for candidate entrypoints and flows:
    - 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 the frozen TC ID, 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 frozen TC plus 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:
+   Read `evidence_path:evidence_line` before using an edge.
+6. Inspect actual code paths that are both relevant to `{feature}` and reachable from navigation/spec/code-index. Prefer `data-testid` for locators. Do not scan excluded historical modules.
+7. Write `source-map.md`, then `mainflow-analysis.md`.
+8. Write `case-descriptions.json` using `references/intermediate-format.md`: one case per TC, locator strings such as `"testid:save-btn"`, `"role:button:确定"`, `"label:用户名"`, and a `covers` mapping that covers every precondition, every step, and the oracle of the TC. Do NOT write raw DSL.
+9. Compile (writes one `TC-xxxx.json` per TC into `.devflow/planning/generated-cases/{feature}/`; all-or-nothing):
 
    ```text
-   devflow_mainflow(action="compile", args=[".planning/generated-cases/{feature}/case-descriptions.json", "--output", ".planning/generated-cases/{feature}/case-import-payloads.json"])
+   devflow_mainflow(action="compile", args=[".devflow/planning/generated-cases/{feature}/case-descriptions.json", "--feature", "{feature}"])
    ```
 
-   Stop if it exits non-zero. The compiler owns all target key selection, strategy decisions, and assertion formatting.
+   Stop and fix the descriptions if it exits non-zero. Do not pass `--output`: it no longer exists (only `--output-dir`, whose default is already the directory above) and the compiler rejects it. Compiler warnings (non-testid locators, high-risk texts) go into `source-map.md`/the handoff; prefer replacing them by a `data-testid`.
 
-11. Validate compiled payloads:
+10. Validate the whole directory (pure data, never loads project code):
 
     ```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"])
+    devflow_mainflow(action="validate", args=[".devflow/planning/generated-cases/{feature}", "--suite", ".devflow/planning/requirements/{feature}/tests.json", "--output", ".devflow/planning/generated-cases/{feature}/validation-report.md"])
     ```
 
-    Stop if it exits non-zero.
+    Stop if it exits non-zero. Read the warnings: an automated ui/api_flow TC listed as having no DSL will be blocked as `dsl_not_approved`.
+
+11. Independent AI review (advisory). Have a different agent than the author review each DSL against its frozen TC: read only the TC (`preconditions`, `steps`, `oracle`) and the DSL, and list omissions, weak assertions, assertions on the wrong object, ambiguous or unstable locators, missing data isolation, and any step that does not follow from the TC. Write the findings per TC to `ai-review.md`. Serious findings should be fixed by editing `case-descriptions.json` and repeating steps 9–11; any DSL byte change invalidates approval for that TC. The review never counts as a pass.
+
+12. Propose an execution plan per automated TC (one item per TC; `dsl_file` defaults to `.devflow/planning/generated-cases/{feature}/{tc_id}.json`):
+
+    ```text
+    devflow_approval(action="propose", feature="{feature}", kind="execution_plan",
+      items=[{"subject":"TC-0001","dsl_file":".devflow/planning/generated-cases/{feature}/TC-0001.json","review_issues":["<advisory issue from ai-review.md>"],"note":"<optional context>"}])
+    ```
 
-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.
+    Core pins `suite_graph_revision`, `suite_fingerprint`, `tc_sha256` and `dsl_sha256` and re-runs structural validation; the proposal is all-or-nothing. It requires database authority. Then ask the user to review each TC (oracle text, covering assertions, review issues) and decide in `/devflow` → “待审批”. Re-running `devflow_approval(action="list", feature="{feature}")` shows proposal status; do not wait on, simulate, or write approvals.
 
-12. Report success only after compilation and validation pass.
+13. Write `.devflow/planning/phases/{phase}/MAINFLOW-CASES.md` summarizing: TC IDs and DSL paths, validation status, review issues, approval proposal status, downgrade candidates, environment data/profile needed.
+14. Report success only after compile, validate, and propose succeeded. Return a handoff containing the source TC IDs, DSL directory, `validation-report.md` and `ai-review.md` paths, proposal IDs/status, required environment/test data, TCs without DSL, and any gaps. Do not advance workflow state.
+
+If a TC's DSL needs to change after it was approved (TC refrozen, code changed, review findings), recompile, revalidate, re-review, and propose again. Recompiling an unchanged description yields byte-identical output, so existing approvals stay valid.
 
 ## AI Scope
 
 AI is responsible for semantic judgment only:
 
-- Determine API/page test scope from frozen `TC-*`, not from implementation delivery prose.
-- 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
+- Decide which frozen TCs are eligible and which need downgrade.
+- Confirm implemented behavior from actual code and bind entrypoints, locators, request paths, and data.
+- Write `case-descriptions.json` faithful to each TC and its `covers`.
+- Record source evidence in `source-map.md`.
+- Review (as a different agent) each DSL against the oracle.
+
+AI is NOT responsible for, and cannot override:
+
+- DSL formatting, `tc_sha256`, target key selection, and step ID assignment (`compile_dsl.py`).
+- Schema, semantic, secret-literal, and structural coverage checks (Core `dsl_v1`/`dsl_coverage` via `validate_case_payloads.py`).
+- The approval of an execution plan or environment profile (only the user, in `/devflow`).
+- Any pass/fail verdict (only Core's `run-acceptance-tests`).
+
+## Legacy export
+
+Only when a developer explicitly asks for a TestAgent import file, run `scripts/export_legacy_testagent.py` directly with a separate legacy-format input and an explicit `--output` (for example `.devflow/planning/generated-cases/{feature}/legacy-testagent-import.json`). It is not exposed by `devflow_mainflow`, is not part of the gate, and its output cannot be bound to `devflow_playwright`, approved as an execution plan, or counted as an acceptance result. Never write its output as `TC-xxxx.json` and never describe it as a Runtime DSL artifact.

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

@@ -1,27 +1,32 @@
 # API Mainflow Rules
 
-API cases validate successful backend behavior through importable DSL.
+这里的 API 用例指冻结的、自动化的 `execution_surface: api_flow` TC：需要多步骤链式请求（变量提取、前后依赖）或 UI/API 组合，用 v1 DSL 表达。单个 Core HTTP 请求且断言来自冻结 TC 的 `execution` 的 API TC 是 `execution_surface: http`，由 Core 的 `http` adapter 直接执行，**不**生成 DSL；带 `execution.expect.error_code` 的异常码 TC 同理，本 Skill 不处理。
+
+AI 写 `case-descriptions.json`（`intermediate-format.md`），`compile_dsl.py` 生成 `TC-xxxx.json`（`project-dsl-contract.md`）。
 
 ## 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.
+- 每个请求是一个 API 步骤：`action` 写 `request` 并给 `method`，或直接写 `get`/`post`/`put`/`patch`/`delete`（`head`/`options` 不支持）。
+- `url` 必填：以 `/` 开头相对已批准 profile 的 `api_base_url`（缺省 `base_url`）；绝对 URL 的 origin 必须在 profile `api_origins` 中。不要把环境相关主机写死，也不要写变量 `${base_url}`（不是内置变量）。
+- 查询参数写 `query`（标量），请求体写 `json`，请求头写 `headers`。
+- 成功断言：`expect_status`，以及响应体断言 `assertions: [{ "pointer": "/data/status", "op": "equals", "value": "created" }]`（`op`：`equals`/`not_equals`/`contains`/`exists`/`not_exists`，JSON Pointer）。只写 `expect_status: 200` 且没有响应体断言，覆盖 oracle 时会被判为弱断言。没有 `status_code`/`json_path_*`/`regex` 之类旧断言类型。
+- 用 `extract: { "order_id": "/data/id" }` 把 id 提取成变量，后续步骤用 `${order_id}`。只支持 JSON Pointer；提取到的令牌等敏感值写 `{ "pointer": "...", "sensitive": true }`。
+- 步骤按写入顺序执行，没有 `depends_on`；失败即停止。
+- 默认不重试；只有传输失败才可声明 `retry`，POST/PATCH 还需 `idempotent: true`。
+- 凭据用 `variables` 的 `{ "secret": "ENV_KEY" }`，请求头写 `"Authorization": "Bearer ${auth_token}"`；不得出现 token/密码/cookie 字面量。
+- 需要前置数据用 `data.setup`，清理用 `data.cleanup`（都只能是 API 步骤）。
 
-## Source Evidence
+## covers 与 TC 忠实性
 
-Cite at least one planning artifact and one code artifact per case:
+- TC 的每个前置条件（对应 `data.setup` 或步骤的 `covers.preconditions`）、每个步骤都要被某个 DSL 步骤覆盖，oracle 要被带 `assertions`/`expect_status` 的主流程 API 步骤覆盖：`covers: ["oracle"]`。
+- DSL 不得增删或改写 TC 的步骤与 oracle；源码只补充路径、字段名和请求体。
+
+## Source Evidence
 
-- 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.
+每个 case 在 `source-map.md` 里至少引用一份规划产物（后端技术方案、变更清单、功能点梳理或需求基线）和一份代码产物（路由/控制器、service/usecase，以及定义契约的 schema/model）。证据不写入 DSL。
 
 ## 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.
+不生成：非法请求、未授权、资源缺失、校验错误、冲突、重试/超时场景、性能场景。这些 TC 走 Core HTTP adapter、项目自有 command 或降级为 `manual`/`blocked`。

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

@@ -1,16 +1,18 @@
 # 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.
+Use discovery before reading feature source files. The goal is to make the skill portable across projects that have valid `.devflow/planning` and `.devflow/context/spec` initialization artifacts.
+
+Discovery only locates code roots so that entrypoints, `data-testid`s, routes, and request shapes can be read for the frozen TCs. It is **not** an input to compilation or validation: `validate_case_payloads.py` is pure data and never loads project code (`--discovery` is deprecated and ignored).
 
 ## 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`
+- `.devflow/planning/STATE.md`
+- `.devflow/planning/navigation/INDEX.md`
+- `.devflow/context/spec/index.md`
+- `.devflow/planning/navigation/{CODEBASE}.md`
+- `.devflow/context/spec/{domain}/{CODEBASE}.md`
 
 Do not infer code roots from common directory names. Treat the navigation/spec registry as the source of truth.
 
@@ -19,13 +21,13 @@ Do not infer code roots from common directory names. Treat the navigation/spec r
 Run:
 
 ```text
-devflow_mainflow(action="discover", args=["--output", ".planning/generated-cases/{feature}/codebase-discovery.json"])
+devflow_mainflow(action="discover", args=["--output", ".devflow/planning/generated-cases/{feature}/codebase-discovery.json"])
 ```
 
 The script must fail if:
 
-- `.planning/navigation/INDEX.md` is missing.
-- `.context/spec/index.md` is missing.
+- `.devflow/planning/navigation/INDEX.md` is missing.
+- `.devflow/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.
@@ -43,7 +45,7 @@ Use `codebase-discovery.json` fields:
 - `codebases[].stack_key`
 - `codebases[].scan_profile`
 
-Current project discovery should resolve `BACKEND` and `FRONTEND`, but this is an output fact, not a skill rule.
+Current project discovery should resolve `BACKEND` and `FRONTEND`, but this is an output fact, not a skill rule. Reading a codebase only supplies binding facts (entry URL, locator, request path); it never changes a frozen TC's steps or oracle.
 
 ## Scan Range By Type