@guanlin4924/devflow-pi 0.1.0

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

@@ -0,0 +1,325 @@
+---
+name: workflow-demand-clarify
+description: "Use when a workflow-wayfinder Grilling ticket needs a focused one-session L1-L4 business clarification. Turns fuzzy requirements into a confirmed, traceable decision scheme. It is not a bypass around the mandatory wayfinder → domain-modeling → feasibility-review chain."
+---
+
+## Legacy Command Metadata
+
+Original slash-command metadata retained for workflow guidance.
+
+```yaml
+argument-hint: <模糊需求描述/链接>
+user-invocable: true
+pattern: inversion+generator
+inputs:
+- 用户的一句话需求/场景描述/业务反馈
+output: .planning/requirements/{功能名}/需求澄清记录.md
+phase-gate:
+  step1: 场景共建：强制反讲确认业务故事
+  step2: 决策驱动：L1-L4 分层决策树问答
+  step3: 分级输出：核心确定区 + 假设验证区 + 决策日志
+resumable: true
+state-key: demand-clarify
+allowed-tools:
+- Read
+- Write
+- Bash
+- Grep
+- Glob
+- ask
+```
+
+# Workflow: Demand Clarify（需求侦探）
+
+把模糊的一句话需求变成可执行、可共识、可追踪的开发方案。
+
+**执行位置**：作为 `workflow-wayfinder` 的 Grilling ticket 工具，在领域建模与可实现性审查之前补齐一个已定位的 L1-L4 决策；不得从分诊直接跳到本技能或需求基线。
+
+## Phase 0 — Wayfinder Ticket 检查
+
+开始前读取 `.planning/requirements/{功能名}/wayfinder/WF-*.md`：
+
+- 仅在当前 Wayfinder Grilling ticket 明确要求一轮 L1-L4 访谈时继续。
+- 若不存在对应 ticket，先执行或回到 `workflow-wayfinder`；不要从分诊直接进入澄清。
+- 若分诊为 `already_done` / `wontfix` / `ready_for_human`，不要继续追问需求；向用户报告分诊结论和证据。
+- 访谈结论必须回写当前 ticket 和决策地图，再继续领域建模与可实现性审查。
+
+## 全局法则：对抗式审查
+
+**在需求侦探阶段就植入攻击视角。不是等代码写完了再找漏洞——那时候修复成本高得多。在需求还没定型的时候，用"如果有人想搞崩这个功能"的角度撞击每个场景和决策。**
+
+### 核心原则
+
+1. **每个场景都配一个"恶意版"** — 正常用户操作了一个场景，立即追问：如果有人用相反/极端/恶意的意图执行同样操作，会发生什么？
+2. **决策影响半径越大，攻击面越大** — L1 战略决策的错误最致命，必须在决策时就要审视攻击面
+3. **不提需求中没有的东西** — 不增加"我们要支持X安全特性"的需求，而是在已有需求中嵌入"这个操作如果被滥用会怎样"的追问
+
+### 应用规则
+
+| 阶段 | 对抗式审查检查点 |
+|------|----------------|
+| Phase 1 场景共建 | 场景清单中增加一列"恶意变体" |
+| Phase 2 L1 战略决策 | 系统边界决策时增加"暴露面"审视 |
+| Phase 2 L2 流程决策 | 每个流程问：绕过审批/跳过状态/超额操作 |
+| Phase 2 L3 节点决策 | 字段校验的缺失 = 注入入口 |
+| Phase 2 生命周期扫描 | 增加"攻击面扫描"维度 |
+| Phase 3 输出 | 假设验证区增加"攻击面假设"
+
+## Outputs
+
+Always create or update:
+
+- `.planning/requirements/{功能名}/需求澄清记录.md` — 包含场景清单、决策日志、分级任务单
+- `.planning/requirements/{功能名}/需求澄清记录.meta.json` — 结构化元数据
+
+### 输出契约（下游消费约定）
+
+下游 `workflow-requirement-baseline` 会读取本技能的产出：
+
+1. **需求澄清记录.md** 中的场景清单 → 作为 baseline 的"原始需求"来源
+2. **决策日志** → 作为 baseline 的 `key_decisions` 元数据输入
+3. **分级任务单** → 核心确定区的 FP 直接进入 baseline；假设验证区的 BR 标记为待确认
+
+本技能不输出的内容（留给下游负责）：
+- `.planning/requirements/baseline.md` — 由 workflow-requirement-baseline 生成
+- `.planning/features/{功能名}/功能点梳理.md` — 由 workflow-feature-breakdown 生成
+- 任何技术方案 — 由 workflow-frontend/backend-tech-spec 生成
+
+## 第一阶段：场景共建
+
+目标：先确认业务故事，不急着给方案。
+
+1. 使用"强制反讲"模板，让用户确认场景故事。
+2. 如果角色、时间、操作、结果、风险不清楚，优先补齐这些信息。
+3. 确认后，整理一张"场景清单"。
+
+基础模板：
+
+```markdown
+## 🔍 场景反讲
+请确认我理解的是否正确：
+> 有一位【用户角色】，在【什么时间/情境下】，他需要【做某操作】，他最关心的是【获得什么结果/避免什么风险】。
+如果不对，请直接纠正这个"故事"，我会重新理解。
+```
+
+场景清单字段：
+- 用户角色
+- 时间/情境
+- 要完成的操作
+- 关心的结果
+- 想避免的风险
+- **恶意变体**：如果这个场景的参与者是恶意的，或者输入数据是极端的，会发生什么？（巨型输入、未来时间、非法状态跳转、重复提交...）
+- 当前不确定点
+
+## 第二阶段：决策驱动
+
+目标：把含糊讨论变成可选择、可承担后果的业务决策。
+
+核心原则：**按决策影响半径由大到小推进**。先确定会改变系统架构、业务边界、数据模型、权限模型的大决策，再根据大决策继续拆解各流程节点的细节决策。
+
+### 决策影响等级
+
+#### L1：战略/边界级决策
+
+会改变项目目标、业务边界、系统建设范围。必须最先确认。
+
+常见问题示例：
+- 这个系统主要服务谁？
+- 资料库是全公司共享还是各自管理？
+- 目标优先级是提升效率还是降低混乱？
+- 是否覆盖多语言、多币种、多组织权限？
+
+输出要求：L1 决策决定模块边界、组织架构、权限模型和项目一期范围。
+
+#### L2：业务模式/流程级决策
+
+会改变核心流程走向、状态机、库存口径和跨部门协作方式。
+
+常见问题示例：
+- 对象之间是一对一、一对多还是多对多？
+- 关键操作是否必须走审批？
+- 操作是否影响库存/状态？
+- 是否允许跨区域调拨？
+
+输出要求：L2 决策决定流程图、状态流转、库存计算和核心业务规则。
+
+#### L3：节点规则/操作级决策
+
+会影响具体页面、按钮、字段、校验和权限控制。
+
+常见问题示例：
+- 谁可以新建/修改资料？
+- 入库/出库是否需要额外操作？
+- 哪些字段必填？
+- 是否允许批量操作？
+
+输出要求：L3 决策决定页面交互、字段规则、权限点、校验逻辑。
+
+#### L4：体验/报表/运营级决策
+
+会影响使用体验、提醒机制、统计报表和运营管理。
+
+常见问题示例：
+- 展示哪些信息？
+- 异常如何提醒？
+- 报表关注哪些指标？
+- 搜索支持哪些筛选条件？
+
+输出要求：L4 决策决定用户体验、运营看板、提醒策略和效率优化功能。
+
+### 决策树推进方法
+
+1. 内部先生成 L1 候选决策题（通常 3-5 个），但用户侧一次只问一个最高阻塞问题。
+2. 用户回答当前最高阻塞问题后，再决定下一个 L1/L2/L3/L4 问题。
+3. 根据 L1 结果生成 L2 流程题：只展开被 L1 选中的业务范围。
+4. 根据 L2 结果生成 L3 节点题：围绕已确定流程逐节点细化。
+5. 最后补 L4 体验和报表题：避免过早讨论锦上添花功能。
+6. 每一层都要说明：这个决策会影响哪些模块、数据、流程、权限或开发成本。
+
+### 业务生命周期扫描规则
+
+在 L2/L3 阶段，对 ERP/业务系统/流程系统类需求，必须按以下维度扫描：
+
+- **对象定义**：管理对象是什么
+- **生命周期**：对象从创建到报废的完整过程
+- **操作动作**：增删改查审批流转等
+- **状态流转**：每个动作前后状态如何变化
+- **审批控制**：哪些动作需要审批
+- **库存/数据影响**：动作是否影响库存或数据一致性
+- **权限边界**：各角色能看什么、改什么
+- **共享策略**：哪些资料共享，哪些隔离
+- **留痕审计**：哪些操作必须记录
+- **异常处理**：异常情况怎么处理
+- **攻击面扫描**：每个操作/输入点如果被恶意利用会怎样？巨型输入、未来时间戳、非法状态跳转、并发重复提交、特殊字符注入——列出每条攻击路径和可能的崩溃点
+- **数据质量**：编码规则、必填字段、校验
+- **报表指标**：最终要看哪些经营指标
+
+### 迷雾战争路由（交给 workflow-wayfinder）
+
+如果澄清过程中发现需求已经超出一轮访谈可控范围，立即停止本技能并切到 `workflow-wayfinder`。触发条件：
+
+- L1 边界仍不清，继续问 L2/L3 会产生大量返工。
+- 多个不确定点互相依赖，需要 Research / Prototype 先解锁。
+- 单个答案会改变大部分后续问题。
+- 预计要拆多个 active slice 才能写出可靠 baseline。
+
+切换时写入 `需求澄清记录.md` 的"转探索原因"，并创建或更新 `.planning/requirements/{功能名}/决策地图.md`。后续由 `workflow-wayfinder` 维护 Destination / Frontier / Fog / Out of Scope 和 Research / Prototype / Grilling / Task ticket。
+
+## 第二阶段.5 — 领域词汇维护（调用 workflow-domain-modeling 纪律）
+
+目标：在产出任务单之前，把本次需求澄清中发现的新领域词汇持久化到 CONTEXT.md，并主动挑战术语边界，避免下游语义不一致。
+
+### 每次决策确认后执行
+
+当用户确认一个 L1-L4 决策时，检查对话中是否出现了**新领域术语**或**术语冲突**：
+
+- **新术语**：业务上第一次出现的概念（如"Workflow"、"订单快照"）
+- **冲突术语**：同一个词在上下文中含义不同（如"取消"=用户操作 vs "取消"=系统自动）
+- **模糊术语**：用户用了泛称但实际有特定含义（如"账号"=客服账号 vs 用户账号）
+
+执行 `workflow-domain-modeling` 的核心纪律：
+
+- 挑战现有词汇表：同词多义、同义多词、代码命名与业务命名冲突都要指出。
+- 主动发明边缘案例：同一用户多角色、状态回滚、历史数据旧口径、跨组织可见性、重复提交等。
+- 只有当决策同时满足 **hard to reverse + surprising + real trade-off** 时才创建 ADR；否则只写入 CONTEXT 或领域模型记录。
+
+### 写入规则
+
+写入 `.planning/CONTEXT.md`：
+
+```markdown
+## 词汇表
+
+| 术语 | 定义 | 反例/不包括 |
+|------|------|-------------|
+| Workflow | 按状态机编排的多步骤业务流程 | 普通单步操作 |
+| 订单快照 | 订单状态变更时的全字段副本 | 当前订单主表最新值 |
+```
+
+如果 `.planning/CONTEXT.md` 不存在，创建它。
+来源、决策层级、对应需求和术语变更历史写入 `.planning/requirements/{功能名}/领域模型记录.md`，不要写入 CONTEXT.md。
+
+### 术语冲突处理
+
+如果发现已有 CONTEXT.md 中的术语定义与当前对话冲突：
+
+1. 立即向用户指出："CONTEXT.md 里将 X 定义为 A，但您说的是 B — 是改定义还是我理解错了？"
+2. 用户确认后更新 CONTEXT.md
+3. 在决策日志中记录术语变更
+
+目标：输出开发能直接理解的分级任务单，并保留决策痕迹。
+
+输出内容：
+
+1. **分级开发任务单**
+   - 核心确定区：必须严格实现
+   - 假设验证区：做成可配置/易修改，上线后根据数据调整
+2. **需求决策日志** Markdown 表格
+
+基础模板：
+
+```markdown
+## 📋 开发任务分级
+### 核心确定区（必须严格实现）
+{{confirmed_logic}}
+
+### 假设验证区（请实现为可配置/易修改）
+{{hypothesis_logic}}
+> ⚠️ 此部分基于当前假设，上线后需根据数据反馈快速调整。
+
+### 攻击面假设（需在上线前做对抗式审查）
+{{attack_surface_hypotheses}}
+> 🛡️ 这些是需求阶段预判的潜在攻击路径，不是确定的需求。下游技术方案和上线前审查必须逐条验证。
+```
+
+```markdown
+## 📝 需求决策日志
+| 日期 | 需求关键词 | 不确定点 | 暂定决策 | 决策人 | 潜在风险 |
+|---|---|---|---|---|---|
+| {{date}} | {{keyword}} | {{uncertainty}} | {{decision}} | {{person}} | {{risk}} |
+```
+
+## 话术库
+
+### 强制反讲话术
+> "我用自己的话复述一下场景：假设你是____，在____时候，你需要____，你最在意的是____。是这样吗？"
+
+### 终极决策话术（对方犹豫时）
+> "那我们先按成本最低的方案A上线验证。但由此产生的数据问题，需要您这边牵头清洗和兜底，可以吗？"
+
+### 默认选择 + 责任声明
+> 如果用户犹豫不决，先用默认选择+责任声明方式推进：先按成本最低方案上线验证，同时明确后续数据/业务兜底责任。
+
+### 示例优先原则（先给再问）
+当用户需要定义**界面/规则/流程/数据结构**时：
+
+1. **先根据已有信息出第一版**：不要问"你想要的页面长什么样"或"这个规则怎么写"，而是先出一版完整的示例（页面布局、规则列表、流程图、字段表）
+2. **让用户改**：用户看到具体的东西才能判断好不好。修改方向比从零描述快 10 倍
+3. **只改不重写**：每次修改都基于上一版，不要每次用户提意见都从头出
+
+适用于：
+- 定义页面布局 / 页面区域划分
+- 定义业务规则 / 判定逻辑
+- 定义状态机 / 流程流转
+- 定义字段列表 / 数据字典
+- 定义筛选条件 / 排序规则
+
+### 开发沟通话术
+> "核心流程A是确定的，必须严格实现。异常处理B这块我们按假设做，请一定做成可配置的，方便上线后快速调整。"
+
+## 相关技能
+
+- `workflow-requirement-triage` — 入口分诊、查重、历史拒绝检查
+- `workflow-wayfinder` — 大需求/迷雾需求的独立探索地图
+- `workflow-domain-modeling` — 领域词汇挑战、边缘案例压测、ADR 门禁
+
+## 使用原则
+
+- 先反讲场景，再讨论方案。
+- 少问"你想怎么做"，多给 A/B 选择题。
+- 决策题必须按影响半径由大到小组织：L1 战略边界 → L2 业务流程 → L3 节点规则 → L4 体验报表。
+- 对每个选择明确业务代价、系统影响和连带影响。
+- 高层决策未确定前，不要过早展开低层细节；低层细节必须服从高层决策。
+- 对不确定逻辑，不假装已经确定；放进"假设验证区"。
+- 对 ERP/流程类需求，必须沿业务生命周期逐节点拆决策点，尤其关注审批、库存、状态、权限、异常、留痕。
+- 最终输出要能给开发、业务、测试三方对齐。

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

@@ -0,0 +1,163 @@
+---
+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."
+---
+
+# Workflow: Domain Modeling（领域模型主动维护）
+
+本技能不是被动记录词汇，而是主动维护项目共同语言：挑战术语、压测边界、减少下游命名和业务理解偏差。需求主链中，它消费 Wayfinder 的 Known Land、Frontier 和已解决 ticket，并将可实现性审查所需的主体、所有权、状态和反例显式化。
+
+## Outputs
+
+Always update when changes are found:
+
+- `.planning/CONTEXT.md`
+- `.planning/requirements/{功能名}/领域模型记录.md`
+- `.planning/requirements/{功能名}/领域模型记录.meta.json`
+
+Only create ADR when the ADR gate passes:
+
+- `.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`
+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.
+
+## Phase 2 — Challenge The Glossary
+
+For each important term in the current conversation or artifact:
+
+1. **Existing definition check**: does `.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?
+5. **Implementation leakage check**: is a business term being defined by table/class details instead of domain meaning?
+
+When a conflict affects requirements, ask one concrete question:
+
+```text
+CONTEXT.md 里「{term}」表示 {old_definition}，但本次需求里它更像 {new_meaning}。
+这里是同一个概念扩展，还是两个不同概念需要分开命名？
+```
+
+## Phase 3 — Invent Edge Cases
+
+For each core relationship, invent at least two edge cases to test whether the domain language is sharp enough:
+
+- Same actor, two roles.
+- Same object, two statuses that sound similar.
+- One operation, two owners.
+- Cross-tenant / cross-organization visibility.
+- Reversal, cancellation, rollback, retry, duplicate submit.
+- Historical data using old vocabulary.
+- Imported data using external vocabulary.
+
+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`
+
+Use this section shape:
+
+```markdown
+## 词汇表
+
+| 术语 | 定义 | 反例/不包括 |
+|------|------|-------------|
+```
+
+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.
+- 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:
+
+```markdown
+## 术语变更记录
+
+| 术语 | 变更类型 | 旧定义 | 新定义 | 来源 | 决策层级 | 对应需求 | 原因 |
+|------|----------|--------|--------|------|----------|----------|------|
+
+## 边缘案例压测
+
+| 术语/关系 | 场景 | 结论 | 是否产生待确认问题 |
+|-----------|------|------|--------------------|
+```
+
+## ADR Gate
+
+Create an ADR only when all three conditions are true:
+
+1. **Hard to reverse**: changing later would require data migration, API compatibility work, user retraining, or cross-module rewrite.
+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.
+
+ADR template:
+
+```markdown
+# ADR-{编号}: {title}
+
+## Status
+Accepted
+
+## Context
+{business context and conflicting options}
+
+## Decision
+{chosen domain decision}
+
+## Consequences
+- Positive: ...
+- Negative: ...
+- Follow-up: ...
+```
+
+## Meta Output
+
+`领域模型记录.meta.json` minimum fields:
+
+```json
+{
+  "feature_name": "",
+  "terms_added": 0,
+  "terms_changed": 0,
+  "term_conflict_count": 0,
+  "edge_case_count": 0,
+  "adr_count": 0,
+  "pending_question_count": 0
+}
+```
+
+## Executable Self-Check
+
+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
+```
+
+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.