@guanlin4924/devflow-pi 0.1.93 → 0.1.95

package/plugins/devflow-quality/skills/workflow-release-closeout/SKILL.md

@@ -11,18 +11,18 @@ description: "在冻结需求验收测试全部通过后，执行 Devflow 自有
 
 ## 必须读取
 
-- `.planning/requirements/{feature}/tests.json`
-- `.planning/test-runs/{feature}/acceptance-results.json`
-- `.planning/features/{feature}/变更清单.md`
-- `.planning/code-index/AUDIT.md`
-- `.planning/PROJECT.md`
-- `.planning/STATE.md`
-- `.planning/navigation/INDEX.md`
+- `.devflow/planning/requirements/{feature}/tests.json`
+- `.devflow/planning/test-runs/{feature}/acceptance-results.json`（先经 `devflow_run_acceptance_tests(action="validate_results", feature=...)` 由 Core 重新校验，再读取用于展示；Markdown 或人工草稿不能替代）
+- `.devflow/planning/features/{feature}/变更清单.md`
+- `.devflow/planning/code-index/AUDIT.md`
+- `.devflow/planning/PROJECT.md`
+- `.devflow/planning/STATE.md`
+- `.devflow/planning/navigation/INDEX.md`
 
 ## 归档前置条件（全部满足）
 
 1. 每个冻结的 `TC-*` 都有执行结果，且结果引用当前测试集 revision/fingerprint。
-2. 不存在 `failed`、`blocked`、未执行或环境缺失的 TC。
+2. 不存在 `failed`、`blocked`、未执行或环境缺失的 TC。这是硬门禁：即使默认 soft 模式，Core 在确认/完成 `release-closeout` 时也会重新校验并以 `acceptance_results_not_passed` 拒绝。
 3. 变更清单任务已完成，TDD/回归证据已存在或有明确豁免。
 4. `code-index` 已刷新，`AUDIT.md` 通过，索引没有 stale blocker。
 5. 需求基线、架构风险和契约没有未处理的阻塞项。
@@ -31,18 +31,18 @@ description: "在冻结需求验收测试全部通过后，执行 Devflow 自有
 
 ## 收口动作
 
-1. 读取 Core-owned `acceptance-results.json`，计算通过/失败/阻塞数量。
-2. 更新 `.planning/navigation/INDEX.md`，记录本次 code-index revision 和验收结果 fingerprint。
-3. 在 `.planning/milestones/` 写入本版本的 ROADMAP、需求覆盖、测试结果、变更清单和已接受风险摘要。
-4. 更新 `.planning/PROJECT.md` 的当前版本与下一步目标。
-5. 通过 Core 状态工具更新 `.planning/STATE.md`，将当前 feature 标记为完成。
+1. 调用 `devflow_run_acceptance_tests(action="validate_results", feature=...)`，让 Core 重新校验 `acceptance-results.json`（suite pins、`execution_surface` 兼容、当前仍有效的 `execution_plan`/`environment_profile`/`human_result`/`mode_override` 批准、运行目录与工件哈希）；运行后 DSL 或 profile 被修改、批准被替换，都会使已记录结果失效，需要回到 `run-acceptance-tests` 重跑；不通过则停止收口。通过后读取该文件（读取即可，不得写入），计算通过/失败/阻塞数量，并展示 `legacy_unclassified`、有效降级记录和逐 TC `dsl_approval`。任何 `dsl_approval: none` 必须对应 blocked；若其被标为 passed、结果未全 passed 或存在未批准降级，立即拒绝收口。人工 TC 的 passed 只来自已确认的 `human_result` approval，`human-acceptance-results.json` 草稿不算证据。
+2. 更新 `.devflow/planning/navigation/INDEX.md`，记录本次 code-index revision 和验收结果 fingerprint。
+3. 在 `.devflow/planning/milestones/` 写入本版本的 ROADMAP、需求覆盖、测试结果、变更清单和已接受风险摘要。
+4. 更新 `.devflow/planning/PROJECT.md` 的当前版本与下一步目标。
+5. 通过 Core 状态工具更新 `.devflow/planning/STATE.md`，将当前 feature 标记为完成。
 6. 归档写入完成后才允许创建 git tag；是否提交或推送由用户明确决定。
 
 ## 输出
 
-- `.planning/milestones/{version}-CLOSEOUT.md`
-- 更新后的 `.planning/PROJECT.md`
-- 更新后的 `.planning/STATE.md`
-- 更新后的 `.planning/navigation/INDEX.md`
+- `.devflow/planning/milestones/{version}-CLOSEOUT.md`
+- 更新后的 `.devflow/planning/PROJECT.md`
+- 更新后的 `.devflow/planning/STATE.md`
+- 更新后的 `.devflow/planning/navigation/INDEX.md`
 
-归档文件是结果摘要，不是通过依据；唯一的验收真相是 Core-owned `acceptance-results.json` 和 code-index 审计结果。
+归档文件是结果摘要，不是通过依据；本地收口依据是由 Core 指定写入并重新校验 pins 的 `acceptance-results.json` 和 code-index 审计结果。这是工作流完整性保障，不是对同用户恶意进程的安全证明；高信任发布必须另外验证外部 attestation。

package/plugins/devflow-quality/skills/workflow-run-acceptance-tests/SKILL.md

@@ -7,11 +7,13 @@ description: "Execute the frozen TC acceptance suite after code review. Use the
 
 此步骤在代码审查后运行。它的目标是执行冻结的 `TC-*`，而不是根据交付总结重新猜测要测什么。
 
+对 `execution_surface: ui|api_flow` 的自动化 TC，`workflow-generate-mainflow-cases` 是本步骤绑定阶段的**真实前置条件**（不是新的主链步骤，也不是可选的开发者同步）：先用它为每个这类 TC 编译 `.devflow/planning/generated-cases/{feature}/TC-xxxx.json`、校验整个目录、独立 AI 审查并提交逐 TC `execution_plan` 批准。没有 DSL 或没有有效批准的 TC 只能 `blocked(dsl_not_approved)`，不得进入收口。
+
 ## 输入边界
 
 测试意图只能读取：
 
-- `.planning/requirements/{feature}/tests.json` 中已冻结且未 stale 的 `TC-*`；
+- `.devflow/planning/requirements/{feature}/tests.json` 中已冻结且未 stale 的 `TC-*`；
 - 图谱中被 TC 引用的已确认 REQ / BR / BC / AC、契约与架构风险；
 - 初始化发现的测试工具链能力。
 
@@ -19,32 +21,36 @@ description: "Execute the frozen TC acceptance suite after code review. Use the
 
 禁止读取或使用以下内容来扩大、缩小或补造验收范围：
 
-- `.planning/phases/{phase}/SUMMARY.md`；
+- `.devflow/planning/phases/{phase}/SUMMARY.md`；
 - agent 的交付自述、代码 diff 或“已完成”结论；
 - 未冻结的临时需求列表。
 
 ## 过程
 
 1. 用 `devflow_acceptance_tests(feature)` 检查测试集已由 CP-3 冻结。若有 stale 或候选 TC，停止并回到需求/测试设计。
-2. 读取冻结 TC 与其 oracle、前置数据、身份和自动化模式。
+2. 读取冻结 TC 与其 oracle、前置数据、身份、自动化模式和 `execution_surface`。
    对 `api_refs`、`workload_refs` 和 `risk_refs` 指向的专项用例，保留其契约、性能/迁移或韧性义务；没有适配器或环境时必须写为 blocked，不能用普通主流程替代。
-3. 读取代码审查报告、代码索引和实际源码，仅为每个 TC 绑定运行适配器；不得改变 TC 的断言、范围或预期。
-4. 写入 `.planning/features/{feature}/acceptance-test-bindings.json`：
+3. 读取代码审查报告、代码索引和实际源码，仅为每个 TC 绑定运行适配器；不得改变 TC 的断言、范围或预期。对每个自动化 `ui|api_flow` TC，若 `generated-cases/{feature}/TC-xxxx.json` 不存在或已过期（TC 重冻结、代码变更），先调用 `workflow-generate-mainflow-cases`；它无法生成的正向 UI/API TC（无稳定 locator、无法准备或隔离数据、纯视觉判断）按下一步降级，异常/边界/权限/性能专项 TC 也不由它生成。
+4. 写入 `.devflow/planning/features/{feature}/acceptance-test-bindings.json`：
    - 固定 `test_suite.graph_revision` 与 `fingerprint`；
    - 每个 TC 恰好一条绑定；
-   - `mode` 必须与冻结 TC 的 `automation_mode` 一致；
-   - 通用自动化用例使用 `{ "kind": "command", "argv": [ ... ] }`，不使用 shell 字符串；
+   - 默认 `mode` 与冻结 TC 的 `automation_mode` 一致。只允许单向降级：`automated → manual|blocked`、`manual → blocked`；`automated → manual` 必须先提交并由用户确认有效的 `mode_override` approval，其他降级必须保留 owner、reason 和 blocked_by；禁止升级；
+   - `execution_surface: ui|api_flow` 必须使用 `{ "kind": "devflow_playwright", "dsl_file": ".devflow/planning/generated-cases/{feature}/TC-xxxx.json", "environment_profile": "local", "timeout_seconds": 600, "artifacts": {"trace":"on_failure","screenshots":"on_failure","max_total_bytes":104857600} }`。绑定不得携带 argv、env、runner、config、result_file 或哈希；
+   - 每个 `devflow_playwright` TC 执行前必须存在有效的逐 TC `execution_plan` approval，profile（`.devflow/planning/test-environments/{profile}.json`）必须存在有效 `environment_profile` approval；缺失、DSL 或 profile 字节变化导致 pins 失效时只能 blocked（`dsl_not_approved` / `environment_profile_not_approved`），不得运行。Agent 用 `devflow_approval(action="propose", kind="environment_profile", items=[{"subject":"{profile}"}])` 提交 profile，用户在 `/devflow` → “待审批”确认；Agent 不能确认，也不能自写批准记录；
+   - `execution_surface: project_test` 的通用自动化用例使用 `{ "kind": "command", "argv": [ ... ] }`，不使用 shell 字符串。命令策略：`npm test` 要求项目已登记 `test` 脚本；`npm|pnpm|yarn run <name>` 要求 `<name>` 是初始化工具链已登记的脚本名，且 `run` 后必须紧跟脚本名（不得在 `run` 之前或之间放选项），额外参数只能放在 `--` 之后；argv 不得引用 `DEVFLOW_` 保留变量或 Devflow Playwright Runtime 路径（那属于 `devflow_playwright`）；
    - Core 生成的 API TC 可直接使用 `{ "kind": "http", "base_url_env": "DEVFLOW_TEST_BASE_URL", "headers_env": { "Authorization": "DEVFLOW_TEST_AUTHORIZATION" } }`。请求、HTTP 状态和异常码断言来自冻结 TC 的 `execution`，绑定只能提供环境地址和鉴权，不得重写测试意图；若场景需要专用夹具，可额外配置 `{ "setup": { "argv": [ ... ] } }`，Core 会先记录并执行该受控命令，再发 HTTP 请求；
-   - 人工或环境阻塞用例必须有 owner 与原因/阻塞源。
+   - 人工用例保留 owner 与执行说明；`human-acceptance-results.json` 仅是草稿和交接材料，最终结果必须来自有效的逐 TC `human_result` approval；
+   - 环境阻塞用例必须有 owner 与阻塞源。
    - `evidence_strategy=causal` 的自动用例额外写 `evidence_files`（项目根目录内的 HAR、控制台、DOM 快照、截图或日志文件相对路径）。Core 在执行前校验文件存在且未越出项目根目录，并把内容哈希写入结果；不能只填 Markdown 描述。
    - `evidence_strategy=observation` 只能保持 `blocked`，其观测计划是风险收口输入，不是测试通过证据。
-5. 调用 `devflow_run_acceptance_tests(action="validate", feature=...)`。不通过时修正绑定，不得绕过。
-6. 调用 `devflow_run_acceptance_tests(action="run", feature=...)`。该 Core 工具记录每个 TC 的命令哈希、退出码和输出摘要。
-7. 失败、未执行或 blocked 的 TC 只能报告为 `blocked`/`failed`，不得进入版本收口。
+5. 调用 `devflow_run_acceptance_tests(action="validate", feature=...)`。它校验 adapter 与 `execution_surface` 的兼容矩阵、`devflow_playwright` 禁用键、DSL 存在且合法、`tc_sha256` 与覆盖。不通过时修正绑定，不得绕过。
+6. 对每个 manual TC，检查用户已在 `/devflow` → “待审批”中确认 `human_result`；Core 按当前 suite fingerprint、`tc_sha256` 和证据哈希重新校验。缺失或失效时保持 blocked。
+7. 调用 `devflow_run_acceptance_tests(action="run", feature=...)`。该 Core 工具执行 automated TC（`devflow_playwright` 在净化环境和独立运行目录中执行，并校验 Runtime 完整性与结果 nonce），合并已校验的 manual TC 结果，并记录命令/证据哈希、退出码、`dsl_approval`、`execution_surface`、`legacy_unclassified` 和降级记录。
+8. 失败、未执行或 blocked 的 TC 只能报告为 `blocked`/`failed`，不得进入版本收口。验收未全 passed 是硬门禁：即使默认 soft 模式，`run-acceptance-tests` 完成和 `release-closeout` 确认时 Core 也会重新校验结果并以 `acceptance_results_not_passed` 拒绝。可用 `devflow_run_acceptance_tests(action="validate_results", feature=...)` 预先检查。该校验会对照当前批准、DSL/profile 哈希与运行目录重新验证每条记录：运行后修改 DSL 或 profile、或批准被新的批准替换，都会使已记录的 passed 失效，必须重跑。
 
 ## 输出
 
-- `.planning/features/{feature}/acceptance-test-bindings.json`
-- `.planning/test-runs/{feature}/acceptance-results.json`
+- `.devflow/planning/features/{feature}/acceptance-test-bindings.json`
+- `.devflow/planning/test-runs/{feature}/acceptance-results.json`
 
-`acceptance-results.json` 是 Core-owned 的执行事实；Markdown 结论不能替代它。
+`acceptance-results.json` 是 Core 指定写入的本地执行缓存（Agent 不得写入，可读取用于展示）；Markdown 结论不能替代它，收口以 Core 对它的重新校验（`validate_results`）为准。Hook 会拦截常规 Write/Edit/Bash 误写，但不是对同一系统用户下任意进程的安全隔离；未配置外部受保护信任根时，不得宣称结果在密码学意义上不可伪造。

package/plugins/devflow-requirements/skills/requirement-feasibility-review/SKILL.md

@@ -15,7 +15,7 @@ In the main delivery chain, run this skill after `workflow-wayfinder` and `workf
 
 Read the raw requirement, meeting decisions, relevant existing requirement artifacts, and only the project/context sources needed to verify claims. Treat a later confirmed meeting decision as higher priority than an earlier conflicting PRD statement.
 
-If the project has `.planning/requirements/{feature}/`, create or update:
+If the project has `.devflow/planning/requirements/{feature}/`, create or update:
 
 - `可实现性审查.md`
 - `可实现性审查.meta.json`

package/plugins/devflow-requirements/skills/workflow-demand-clarify/SKILL.md

@@ -13,7 +13,7 @@ user-invocable: true
 pattern: inversion+generator
 inputs:
 - 用户的一句话需求/场景描述/业务反馈
-output: .planning/requirements/{功能名}/需求澄清记录.md
+output: .devflow/planning/requirements/{功能名}/需求澄清记录.md
 phase-gate:
   step1: 场景共建：强制反讲确认业务故事
   step2: 决策驱动：L1-L4 分层决策树问答
@@ -37,7 +37,7 @@ allowed-tools:
 
 ## Phase 0 — Wayfinder Ticket 检查
 
-开始前读取 `.planning/requirements/{功能名}/wayfinder/WF-*.md`：
+开始前读取 `.devflow/planning/requirements/{功能名}/wayfinder/WF-*.md`：
 
 - 仅在当前 Wayfinder Grilling ticket 明确要求一轮 L1-L4 访谈时继续。
 - 若不存在对应 ticket，先执行或回到 `workflow-wayfinder`；不要从分诊直接进入澄清。
@@ -69,8 +69,8 @@ allowed-tools:
 
 Always create or update:
 
-- `.planning/requirements/{功能名}/需求澄清记录.md` — 包含场景清单、决策日志、分级任务单
-- `.planning/requirements/{功能名}/需求澄清记录.meta.json` — 结构化元数据
+- `.devflow/planning/requirements/{功能名}/需求澄清记录.md` — 包含场景清单、决策日志、分级任务单
+- `.devflow/planning/requirements/{功能名}/需求澄清记录.meta.json` — 结构化元数据
 
 ### 输出契约（下游消费约定）
 
@@ -81,8 +81,8 @@ Always create or update:
 3. **分级任务单** → 核心确定区的 FP 直接进入 baseline；假设验证区的 BR 标记为待确认
 
 本技能不输出的内容（留给下游负责）：
-- `.planning/requirements/baseline.md` — 由 workflow-requirement-baseline 生成
-- `.planning/features/{功能名}/功能点梳理.md` — 由 workflow-feature-breakdown 生成
+- `.devflow/planning/requirements/baseline.md` — 由 workflow-requirement-baseline 生成
+- `.devflow/planning/features/{功能名}/功能点梳理.md` — 由 workflow-feature-breakdown 生成
 - 任何技术方案 — 由 workflow-frontend/backend-tech-spec 生成
 
 ## 第一阶段：场景共建
@@ -203,7 +203,7 @@ Always create or update:
 - 单个答案会改变大部分后续问题。
 - 预计要拆多个 active slice 才能写出可靠 baseline。
 
-切换时写入 `需求澄清记录.md` 的"转探索原因"，并创建或更新 `.planning/requirements/{功能名}/决策地图.md`。后续由 `workflow-wayfinder` 维护 Destination / Frontier / Fog / Out of Scope 和 Research / Prototype / Grilling / Task ticket。
+切换时写入 `需求澄清记录.md` 的"转探索原因"，并创建或更新 `.devflow/planning/requirements/{功能名}/决策地图.md`。后续由 `workflow-wayfinder` 维护 Destination / Frontier / Fog / Out of Scope 和 Research / Prototype / Grilling / Task ticket。
 
 ## 第二阶段.5 — 领域词汇维护（调用 workflow-domain-modeling 纪律）
 
@@ -225,7 +225,7 @@ Always create or update:
 
 ### 写入规则
 
-写入 `.planning/CONTEXT.md`：
+写入 `.devflow/planning/CONTEXT.md`：
 
 ```markdown
 ## 词汇表
@@ -236,8 +236,8 @@ Always create or update:
 | 订单快照 | 订单状态变更时的全字段副本 | 当前订单主表最新值 |
 ```
 
-如果 `.planning/CONTEXT.md` 不存在，创建它。
-来源、决策层级、对应需求和术语变更历史写入 `.planning/requirements/{功能名}/领域模型记录.md`，不要写入 CONTEXT.md。
+如果 `.devflow/planning/CONTEXT.md` 不存在，创建它。
+来源、决策层级、对应需求和术语变更历史写入 `.devflow/planning/requirements/{功能名}/领域模型记录.md`，不要写入 CONTEXT.md。
 
 ### 术语冲突处理
 

package/plugins/devflow-requirements/skills/workflow-domain-modeling/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-domain-modeling
-description: "Use as the mandatory domain-modeling step after workflow-wayfinder and before requirement-feasibility-review; also use during later clarification or planning when domain terms, business concepts, status names, ownership, or decision records may be ambiguous. Challenges the glossary, stress-tests relationships, updates .planning/CONTEXT.md, and creates ADR notes only for hard-to-reverse surprising trade-offs."
+description: "Use as the mandatory domain-modeling step after workflow-wayfinder and before requirement-feasibility-review; also use during later clarification or planning when domain terms, business concepts, status names, ownership, or decision records may be ambiguous. Challenges the glossary, stress-tests relationships, updates .devflow/planning/CONTEXT.md, and creates ADR notes only for hard-to-reverse surprising trade-offs."
 ---
 
 # Workflow: Domain Modeling（领域模型主动维护）
@@ -11,25 +11,25 @@ description: "Use as the mandatory domain-modeling step after workflow-wayfinder
 
 Always update when changes are found:
 
-- `.planning/CONTEXT.md`
-- `.planning/requirements/{功能名}/领域模型记录.md`
-- `.planning/requirements/{功能名}/领域模型记录.meta.json`
+- `.devflow/planning/CONTEXT.md`
+- `.devflow/planning/requirements/{功能名}/领域模型记录.md`
+- `.devflow/planning/requirements/{功能名}/领域模型记录.meta.json`
 
 Only create ADR when the ADR gate passes:
 
-- `.planning/adr/{编号}-{slug}.md`
+- `.devflow/planning/adr/{编号}-{slug}.md`
 
 ## Phase 1 — Load Existing Language
 
 Read, if present:
 
-1. `.planning/CONTEXT.md`
-2. `.planning/requirements/{功能名}/决策地图.md`
-3. `.planning/requirements/{功能名}/wayfinder/WF-*.md` 中已解决 ticket
-4. `.planning/requirements/baseline.md`
-5. `.planning/features/**/需求梳理.md`
-6. `.planning/features/**/需求澄清记录.md`
-7. `.planning/*/CONTEXT.md`
+1. `.devflow/planning/CONTEXT.md`
+2. `.devflow/planning/requirements/{功能名}/决策地图.md`
+3. `.devflow/planning/requirements/{功能名}/wayfinder/WF-*.md` 中已解决 ticket
+4. `.devflow/planning/requirements/baseline.md`
+5. `.devflow/planning/features/**/需求梳理.md`
+6. `.devflow/planning/features/**/需求澄清记录.md`
+7. `.devflow/planning/*/CONTEXT.md`
 8. Relevant source names from navigation: model names, table names, enum/status constants, route names, page titles
 
 Do not load broad source bodies unless a term conflict depends on exact code behavior.
@@ -38,7 +38,7 @@ Do not load broad source bodies unless a term conflict depends on exact code beh
 
 For each important term in the current conversation or artifact:
 
-1. **Existing definition check**: does `.planning/CONTEXT.md` already define it?
+1. **Existing definition check**: does `.devflow/planning/CONTEXT.md` already define it?
 2. **Collision check**: is the same word used for multiple concepts?
 3. **Synonym check**: are multiple words used for the same concept?
 4. **Code-language check**: do routes, models, fields, enum constants, and UI labels use different names?
@@ -65,7 +65,7 @@ For each core relationship, invent at least two edge cases to test whether the d
 
 If an edge case changes the meaning of a term, update the glossary or create a pending question. Do not turn edge cases into new scope automatically.
 
-## Phase 4 — Update `.planning/CONTEXT.md`
+## Phase 4 — Update `.devflow/planning/CONTEXT.md`
 
 Use this section shape:
 
@@ -81,7 +81,7 @@ Rules:
 - Definition must be domain-facing, not implementation-facing.
 - Add `反例/不包括` whenever a term could be confused with a neighbor concept.
 - Preserve existing terms unless the user confirmed a replacement.
-- Keep `.planning/CONTEXT.md` pure glossary. Do not store implementation details, FP/BR/BC IDs, source paths, requirement traceability, decision levels, or change history in it.
+- Keep `.devflow/planning/CONTEXT.md` pure glossary. Do not store implementation details, FP/BR/BC IDs, source paths, requirement traceability, decision levels, or change history in it.
 - If a definition changes, record the old definition, new definition, reason, source, decision level, related requirement, and edge cases in `领域模型记录.md`.
 
 Use `领域模型记录.md` for traceability:
@@ -106,7 +106,7 @@ Create an ADR only when all three conditions are true:
 2. **Surprising**: a future developer could reasonably choose a different direction without this record.
 3. **Real trade-off**: at least two credible options exist and each has a cost.
 
-If any condition is false, record the decision in `领域模型记录.md` or `.planning/CONTEXT.md`, not ADR.
+If any condition is false, record the decision in `领域模型记录.md` or `.devflow/planning/CONTEXT.md`, not ADR.
 
 ADR template:
 
@@ -153,15 +153,15 @@ Submit bounded candidates through `devflow_requirement_graph`: use `term` for sh
 When this run adds or changes domain language, replace `<feature>` and run:
 
 ```bash
-test -s .planning/CONTEXT.md
-test -s .planning/requirements/<feature>/领域模型记录.md
-python3 -m json.tool .planning/requirements/<feature>/领域模型记录.meta.json >/dev/null
-grep -q '"feature_name"' .planning/requirements/<feature>/领域模型记录.meta.json
-grep -q '"terms_added"' .planning/requirements/<feature>/领域模型记录.meta.json
-grep -q '"terms_changed"' .planning/requirements/<feature>/领域模型记录.meta.json
-grep -q '## 词汇表' .planning/CONTEXT.md
-grep -q '## 术语变更记录' .planning/requirements/<feature>/领域模型记录.md
-grep -q '## 边缘案例压测' .planning/requirements/<feature>/领域模型记录.md
+test -s .devflow/planning/CONTEXT.md
+test -s .devflow/planning/requirements/<feature>/领域模型记录.md
+python3 -m json.tool .devflow/planning/requirements/<feature>/领域模型记录.meta.json >/dev/null
+grep -q '"feature_name"' .devflow/planning/requirements/<feature>/领域模型记录.meta.json
+grep -q '"terms_added"' .devflow/planning/requirements/<feature>/领域模型记录.meta.json
+grep -q '"terms_changed"' .devflow/planning/requirements/<feature>/领域模型记录.meta.json
+grep -q '## 词汇表' .devflow/planning/CONTEXT.md
+grep -q '## 术语变更记录' .devflow/planning/requirements/<feature>/领域模型记录.md
+grep -q '## 边缘案例压测' .devflow/planning/requirements/<feature>/领域模型记录.md
 ```
 
 Pass only when every command exits with code 0, the metadata is valid JSON with the required counters, and each changed term has both a domain-facing glossary definition and a traceability record. If no language changed, record that no-change conclusion in the feature's domain-model record; do not create an ADR. If a check fails, repair the glossary, record, or metadata before continuing to baseline or technical planning.

package/plugins/devflow-requirements/skills/workflow-requirement-baseline/SKILL.md

@@ -12,12 +12,12 @@ argument-hint: '[@需求文档.md]'
 user-invocable: true
 pattern: inversion+generator+reviewer
 inputs:
-- .planning/PROJECT.md
-- .planning/navigation/INDEX.md
-- .planning/navigation/*.md
-- .planning/milestones/
+- .devflow/planning/PROJECT.md
+- .devflow/planning/navigation/INDEX.md
+- .devflow/planning/navigation/*.md
+- .devflow/planning/milestones/
 - 原始需求文档/PRD/会议纪要/用户描述
-output: .planning/requirements/baseline.md
+output: .devflow/planning/requirements/baseline.md
 phase-gate:
   step1: 加载项目上下文和原始需求
   step2: 需求整理：结构化原文信息
@@ -47,10 +47,10 @@ This skill receives raw requirements and turns them into a stable requirement ba
 
 Before Phase 1, check these mandatory upstream artifacts:
 
-- `.planning/requirements/{feature}/入口分诊.md` and `.meta.json`;
-- `.planning/requirements/{feature}/决策地图.md` and `.meta.json`;
-- `.planning/requirements/{feature}/领域模型记录.md` and `.meta.json`;
-- `.planning/requirements/{feature}/可实现性审查.md` and `.meta.json`.
+- `.devflow/planning/requirements/{feature}/入口分诊.md` and `.meta.json`;
+- `.devflow/planning/requirements/{feature}/决策地图.md` and `.meta.json`;
+- `.devflow/planning/requirements/{feature}/领域模型记录.md` and `.meta.json`;
+- `.devflow/planning/requirements/{feature}/可实现性审查.md` and `.meta.json`.
 
 If any are missing, run the earliest missing main-chain step. Baseline must not become the first place where duplicate capability, fog, terminology ambiguity, or feasibility gaps are discovered.
 
@@ -105,24 +105,24 @@ When triage found partial overlap or prior rejection, preserve it as source mate
 
 Always create or update:
 
-- `.planning/requirements/baseline.md` — unified requirement baseline
-- `.planning/requirements/baseline.meta.json` — structured metadata. Schema defined in `feature-development.yaml` under `steps[requirement-baseline].meta_output.fields`: `review_status`, `fp_count`, `br_count`, `bc_count`, `blocking_pending_count`, `critical_image_missing_count`, `challenge_pending_count`, `code_reality_missing_count`, `current_feature`, `depends_on_count`, plus optional `pending_items`, `risks`, and `key_decisions`.
-- `.planning/requirements/{feature}/traceability.json` — copy the orchestrator `templates/traceability.json` schema and create one atomic `REQ-*` record for every confirmed in-scope requirement. Every record must define `input`、`output`、`behavior`、`orchestration`、`failure`、`verification`; use `N/A` only with a reason when a dimension truly does not apply.
+- `.devflow/planning/requirements/baseline.md` — unified requirement baseline
+- `.devflow/planning/requirements/baseline.meta.json` — structured metadata. Schema defined in `feature-development.yaml` under `steps[requirement-baseline].meta_output.fields`: `review_status`, `fp_count`, `br_count`, `bc_count`, `blocking_pending_count`, `critical_image_missing_count`, `challenge_pending_count`, `code_reality_missing_count`, `current_feature`, `depends_on_count`, plus optional `pending_items`, `risks`, and `key_decisions`.
+- `.devflow/planning/requirements/{feature}/traceability.json` — copy the orchestrator `templates/traceability.json` schema and create one atomic `REQ-*` record for every confirmed in-scope requirement. Every record must define `input`、`output`、`behavior`、`orchestration`、`failure`、`verification`; use `N/A` only with a reason when a dimension truly does not apply.
 
 Before the CP-1 result is reported, run:
 
 ```bash
-python3 <workflow-orchestrator>/scripts/traceability_check.py --file .planning/requirements/{feature}/traceability.json --stage baseline
+python3 <workflow-orchestrator>/scripts/traceability_check.py --file .devflow/planning/requirements/{feature}/traceability.json --stage baseline
 ```
 
 Set `baseline.meta.json.traceability_status` to `passed` only when that command succeeds. A failed traceability check is a blocking baseline defect, not a deferred documentation suggestion.
 
 Do not create by default:
 
-- `.planning/features/{功能名}/功能点梳理.md`
-- `.planning/features/{功能名}/前端技术方案.md`
-- `.planning/features/{功能名}/后端技术方案.md`
-- `.planning/features/{功能名}/变更清单.md`
+- `.devflow/planning/features/{功能名}/功能点梳理.md`
+- `.devflow/planning/features/{功能名}/前端技术方案.md`
+- `.devflow/planning/features/{功能名}/后端技术方案.md`
+- `.devflow/planning/features/{功能名}/变更清单.md`
 
 ## Argument Handling
 
@@ -135,21 +135,21 @@ If both a requirement document and pasted text are provided, use both and record
 
 ### 上游契约（与本技能串联的上游流程）
 
-当 `.planning/requirements/{feature}/入口分诊.md` 存在时（由 `workflow-requirement-triage` 生成）：
+当 `.devflow/planning/requirements/{feature}/入口分诊.md` 存在时（由 `workflow-requirement-triage` 生成）：
 
 1. 将分诊分类写入 `baseline.meta.json.requirement_type` 或需求来源摘要。
 2. 将 `related_code_paths` 作为 Phase 1.5/4 的优先检查入口，但不能直接当作行为结论。
 3. 将 `related_history_paths` 和 prior rejection 记录纳入 Phase 4.5 Challenge Review。
 4. 如果 `route` 不是 `ready_for_wayfinder`，按 Phase 0 路由停止或切换技能。
 
-当 `.planning/requirements/{feature}/决策地图.md` 存在时（由 `workflow-wayfinder` 生成）：
+当 `.devflow/planning/requirements/{feature}/决策地图.md` 存在时（由 `workflow-wayfinder` 生成）：
 
 1. 只有 `决策地图.meta.json.ready_for_baseline = true` 才可继续 baseline。
 2. Destination 和 Known Land 作为需求来源。
-3. 读取 `.planning/requirements/{feature}/wayfinder/WF-*.md` 中 `status=resolved` 的 ticket；其 Findings / Answer 转为 FP/BR/BC 或 `反向审视与用户拍板` 记录。
+3. 读取 `.devflow/planning/requirements/{feature}/wayfinder/WF-*.md` 中 `status=resolved` 的 ticket；其 Findings / Answer 转为 FP/BR/BC 或 `反向审视与用户拍板` 记录。
 4. Open ticket 只能进入待确认或后置探索，不能伪装成已确认需求。
 
-当 `.planning/requirements/{feature}/需求澄清记录.md` 存在时（由 `workflow-demand-clarify` 生成）：
+当 `.devflow/planning/requirements/{feature}/需求澄清记录.md` 存在时（由 `workflow-demand-clarify` 生成）：
 
 1. 优先以 **需求澄清记录.md** 的场景清单和分级任务单作为原始需求来源
 2. 将决策日志中的 L1-L4 决策结论转化为 `key_decisions` 元数据
@@ -157,14 +157,14 @@ If both a requirement document and pasted text are provided, use both and record
 4. 假设验证区内容进入 BR（业务规则），标记为"待上线验证"
 5. 不需要再对用户做"场景反讲"等基础澄清——这些已经在 demand-clarify 阶段完成
 
-当 `.planning/requirements/{feature}/领域模型记录.md` 或 `.planning/CONTEXT.md` 存在时（由 `workflow-domain-modeling` 维护）：
+当 `.devflow/planning/requirements/{feature}/领域模型记录.md` 或 `.devflow/planning/CONTEXT.md` 存在时（由 `workflow-domain-modeling` 维护）：
 
-1. `.planning/CONTEXT.md` 只作为纯词汇表读取，不从中读取需求追溯。
+1. `.devflow/planning/CONTEXT.md` 只作为纯词汇表读取，不从中读取需求追溯。
 2. 使用已确认术语写 FP/BR/BC 名称，避免同义多词。
 3. 从 `领域模型记录.md` 读取术语冲突、边缘案例压力测试和追溯信息，并纳入 Phase 4/7 审查。
 4. ADR 只作为需求决策证据，不展开技术方案。
 
-当 `.planning/requirements/{feature}/可实现性审查.md` 存在时（由 `requirement-feasibility-review` 维护）：
+当 `.devflow/planning/requirements/{feature}/可实现性审查.md` 存在时（由 `requirement-feasibility-review` 维护）：
 
 1. 仅消费其中 `SOURCE_FACT`、`CONFIRMED_DECISION` 和已接受实现方向；不得把 `DERIVED_QUESTION` 或 `ASSUMPTION` 写入 baseline。
 2. 将审查已确认的范围排除、外部能力边界、入口门禁和存量兼容规则转化为 FP/BR/BC。
@@ -174,7 +174,7 @@ If both a requirement document and pasted text are provided, use both and record
 
 **叠加原则：baseline.md 是需求的累积目录，不是单功能快照。每次新增需求时，在已有内容上追加，不覆盖。**
 
-If `.planning/requirements/baseline.md` already exists:
+If `.devflow/planning/requirements/baseline.md` already exists:
 
 1. Read it before restructuring new input. Understand ALL existing features, not just the current one.
 2. **Preserve all confirmed `FP-*`, `BR-*`, `BC-*` from previous features.** Do not delete, renumber, or silently drop them.
@@ -193,7 +193,7 @@ Each new requirement gets its own stable `{功能名}`. **This is additive — a
 3. Keep it short, stable, and safe as a path segment.
 4. Once written to baseline, do not change it in later clarification unless the user explicitly renames the feature.
 5. If the feature name changes, record the old name, new name, reason, and downstream directory impact in `澄清与变更记录`.
-6. The canonical downstream output directory is `.planning/features/{功能名}/`. Multiple features → multiple directories.
+6. The canonical downstream output directory is `.devflow/planning/features/{功能名}/`. Multiple features → multiple directories.
 7. Legacy root `features/{功能名}/` may be read as historical evidence only; new workflow outputs must not use it.
 8. When baseline already has features, the new `{功能名}` must be distinct from existing ones unless the user explicitly says it's an iteration on the same feature.
 
@@ -220,21 +220,21 @@ Load bundled resources only when needed:
 
 Load available project context:
 
-1. `.planning/PROJECT.md`
-2. `.planning/navigation/INDEX.md`
-3. `.planning/navigation/INDEX.md` for the Codebase Registry — identify which codebases are relevant to the requirement
-4. Load the navigation files (`.planning/navigation/{name}.md`) for each relevant codebase from the registry
-5. If `.planning/code-index/` exists, note that `code-index-query` must be used for Phase 1.5 routing and Phase 4 source-reality checks
-6. `.planning/milestones/`
-7. `.planning/requirements/`
-8. `.planning/lessons/`
-9. `.planning/*/CONTEXT.md`
+1. `.devflow/planning/PROJECT.md`
+2. `.devflow/planning/navigation/INDEX.md`
+3. `.devflow/planning/navigation/INDEX.md` for the Codebase Registry — identify which codebases are relevant to the requirement
+4. Load the navigation files (`.devflow/planning/navigation/{name}.md`) for each relevant codebase from the registry
+5. If `.devflow/planning/code-index/` exists, note that `code-index-query` must be used for Phase 1.5 routing and Phase 4 source-reality checks
+6. `.devflow/planning/milestones/`
+7. `.devflow/planning/requirements/`
+8. `.devflow/planning/lessons/`
+9. `.devflow/planning/*/CONTEXT.md`
 
 History model rule:
 
 - This workflow's primary historical artifacts are milestone and planning artifacts, not outbound-call style `features/*.spec.md` files.
-- Use `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and `.planning/*/CONTEXT.md` first.
-- If `features/`, `.context/lessons/`, or `.context/workflow/` exist in the target project, treat them as optional legacy/project-rule evidence and record that distinction.
+- Use `.devflow/planning/milestones/`, `.devflow/planning/requirements/`, `.devflow/planning/lessons/`, and `.devflow/planning/*/CONTEXT.md` first.
+- If `features/`, `.devflow/context/lessons/`, or `.devflow/context/workflow/` exist in the target project, treat them as optional legacy/project-rule evidence and record that distinction.
 
 Then collect this requirement input:
 
@@ -289,16 +289,16 @@ Use this wording pattern when blocked by an image:
 
 **混合类型**：一个需求可能同时涉及多种类型（如 A+D 混合）。标记为主类型+副类型（如 `A+D`），后续 Phase 按主类型流程推进，在 Phase 3.5 和 Phase 4 兼顾副类型的检查项。
 
-写入 `.planning/requirements/baseline.meta.json` 的 `requirement_type` 字段。
+写入 `.devflow/planning/requirements/baseline.meta.json` 的 `requirement_type` 字段。
 
 ### 1.5.3 Code routing scan before questions
 
 Before asking the user any clarification question, produce an internal code routing summary from project artifacts:
 
-1. Use `.planning/navigation/INDEX.md` to identify relevant codebases.
-2. Read the relevant navigation files (`.planning/navigation/BACKEND.md`, `.planning/navigation/FRONTEND.md`, or other registered codebase files).
+1. Use `.devflow/planning/navigation/INDEX.md` to identify relevant codebases.
+2. Read the relevant navigation files (`.devflow/planning/navigation/BACKEND.md`, `.devflow/planning/navigation/FRONTEND.md`, or other registered codebase files).
 3. Treat navigation as a routing index only. It helps find files quickly, but it is not sufficient evidence for requirement conclusions.
-4. If `.planning/code-index/` exists, use `code-index-query` with requirement concepts to find candidate routes/pages/services/models/tests/resources. Treat these as routing candidates only.
+4. If `.devflow/planning/code-index/` exists, use `code-index-query` with requirement concepts to find candidate routes/pages/services/models/tests/resources. Treat these as routing candidates only.
 5. Confirm likely related source paths exist by listing directories or opening only top-level file structure, imports, class/function names, route declarations, comments, and short module headers.
 6. Do not inspect function bodies, branch logic, data flow, SQL/query details, permission checks, or state transitions in Phase 1.5. Those are Phase 4 Level 2 responsibilities.
 7. Do not conclude "already supported", "not supported", or "conflicting" in Phase 1.5. Only record "possibly related" modules and why they should be checked later.
@@ -471,7 +471,7 @@ seam_type: "新建" | "扩展" | "修改"
 module_depth: "深" | "浅（需下游关注）" | "待评估"
 ```
 
-写入 `.planning/requirements/baseline.md` 中每个 FP 的描述末尾。
+写入 `.devflow/planning/requirements/baseline.md` 中每个 FP 的描述末尾。
 
 ### 完成门禁
 
@@ -508,7 +508,7 @@ Review the decomposed feature points for:
 
 **Level 1: 导航 Call Chain Map 对照（结构层）**
 - 对每个涉及已有代码的 FP，从导航文件的 API Modules / Route-Component Map 提取受影响文件清单
-- 若 `.planning/code-index/` 存在，必须通过 `code-index-query` 用需求关键词、API 路径、页面名、字段名、状态名、表/配置/资源名查询 Symbol Index 和 Relation Graph，补充 navigation 未覆盖的调用方、被调用方、入口和数据流候选
+- 若 `.devflow/planning/code-index/` 存在，必须通过 `code-index-query` 用需求关键词、API 路径、页面名、字段名、状态名、表/配置/资源名查询 Symbol Index 和 Relation Graph，补充 navigation 未覆盖的调用方、被调用方、入口和数据流候选
 - 调用链重叠类型判断：扩展已有 vs 新建分支
 - 契约影响预判：修改已有接口时检查其他调用方
 - 导航无候选时，先通过 `code-index-query` 查 code-index；仍无候选时，再用需求关键词、API 路径、页面名、字段名、状态名通过 `rg` 查实际源码。navigation 不能作为"无相关代码"的唯一证据
@@ -618,7 +618,7 @@ After every user answer in Phase 5:
 
 **叠加模式（baseline 已存在）**：
 
-1. Read existing `.planning/requirements/baseline.md` as the base.
+1. Read existing `.devflow/planning/requirements/baseline.md` as the base.
 2. Append new feature points after the existing ones. Keep all old FP-*, BR-*, BC-* intact.
 3. Update `需求来源` to add the new source entry.
 4. Update `当前功能切片` to list only the current feature's FP/BR/BC IDs, active `SL-*`, deferred slices, and any `depends_on` historical references.
@@ -634,10 +634,10 @@ After every user answer in Phase 5:
 
 Read `assets/baseline-template.md`.
 
-Generate `.planning/requirements/baseline.md` with:
+Generate `.devflow/planning/requirements/baseline.md` with:
 
 - Requirement source summary
-- Feature name and canonical output directory, using one stable `{功能名}` for all downstream `.planning/features/{功能名}/...` outputs
+- Feature name and canonical output directory, using one stable `{功能名}` for all downstream `.devflow/planning/features/{功能名}/...` outputs
 - Structured requirement summary
 - Current feature slice with current FP/BR/BC IDs
 - Slice plan with active `SL-*`, deferred slices, dependencies, and gates
@@ -655,11 +655,11 @@ Generate `.planning/requirements/baseline.md` with:
 - Clarification and change log
 - Review result
 
-Create `.planning/requirements/` if needed.
+Create `.devflow/planning/requirements/` if needed.
 
 Do not create synonym duplicate sections such as `需求来源汇总` or `历史影响` when the template section is named `需求来源` or `与历史功能/里程碑的关联`.
 
-Write `.planning/requirements/baseline.meta.json` with the fields required by the workflow YAML. `review_status` must be `passed` only when the baseline review conclusion is `通过`; otherwise use `failed`. Count blocking items explicitly:
+Write `.devflow/planning/requirements/baseline.meta.json` with the fields required by the workflow YAML. `review_status` must be `passed` only when the baseline review conclusion is `通过`; otherwise use `failed`. Count blocking items explicitly:
 
 - `blocking_pending_count`: unanswered clarification items that block reliable baseline or downstream handoff
 - `critical_image_missing_count`: missing or unclear `critical_image` items
@@ -731,7 +731,7 @@ Completion gate: baseline and baseline.meta.json are written and contain no unre
 
 Before claiming baseline readiness, submit `requirement`、`rule`、`boundary`、`slice` and `acceptance` candidates through `devflow_requirement_graph`. Each requirement candidate must cite source IDs and reference behavior/acceptance IDs returned by the writer. Run `devflow_requirement_graph(action="validate")` and record its result in baseline metadata. Do not directly create `governance.json`, allocate IDs, or set candidate status to `confirmed`.
 
-The baseline handoff must also call `devflow_requirement_graph(action="inspect")` after all proposals and validation. Record the returned graph `revision` and the SHA-256 of `.planning/requirements/{feature}/governance.json` as `graph_revision` and `governance_graph_sha256` in `baseline.meta.json`. The step is not complete if the Core-owned graph file, revision, or hash is missing.
+The baseline handoff must also call `devflow_requirement_graph(action="inspect")` after all proposals and validation. Record the returned graph `revision` and the SHA-256 of `.devflow/planning/requirements/{feature}/governance.json` as `graph_revision` and `governance_graph_sha256` in `baseline.meta.json`. The step is not complete if the Core-owned graph file, revision, or hash is missing.
 
 ```markdown
 - [ ] 每个原始需求映射到 FP-*/BR-*/BC-* 或 out-of-scope