wangmian/OneOS1.2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

扩展氢能站点、加氢记录与台账原型链路，新增工作台、车辆资产 H5、自营物流等原型，并同步导航注册、PRD 资源与交付技能。

Browse Source 
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
王冕
2026-07-21 17:15:39 +08:00
parent e39df1c7c8
commit a01d2ab708
242 changed files with 102296 additions and 4866 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
.cursor/skills/yunxiao-requirement-lifecycle/references/auto-stage-task.md Normal file
View File

@@ -0,0 +1,62 @@
# 需求进阶段自动建同名任务（强制 · AI 桥接）
当**产品类需求**推进到下列状态时，AI（`apply`）必须查重后创建/复用**与需求同名**的任务，并**正式关联**该需求。不得只改需求状态却不建任务。
## 触发状态与字段规则
| 需求进入状态 | 任务标题 | 任务标签（右侧基础字段） | 负责人 | 时间字段 |
|---|---|---|---|---|
| **分析中** | = 需求标题（同名） | `分析` | **需求创建人**姓名 | 沿用需求（见下） |
| **设计中** | = 需求标题（同名） | `设计` | **需求创建人**姓名 | 沿用需求（见下） |
| **待开发** | = 需求标题（同名） | `交付`（OneOS 主任务）；若项目仍用阶段开发标签则用 `开发` | 固定 **何斐** | 沿用需求（见下） |
### 时间沿用（「标签创建时间沿用需求的」）
按平台能力尽量对齐，优先级：
1. 任务 **计划开始时间** = 需求的计划开始时间；若需求无计划开始，则用需求 **创建时间** 的日期。
2. 若平台允许写入任务创建时间：任务创建时间 = 需求创建时间。
3. 若都不能改创建时间：仍写计划开始；并在任务描述首行注明：`创建时间沿用需求：YYYY-MM-DD HH:mm`。
### 正式关联（强制）
- 使用云效**父子项或关联项**把任务挂到**该产品需求**。
- 仅标题写需求编号、或只关联其他任务而不关联需求 → **不合格**，必须补关联后再回报成功。
- 标题前缀（如 `【分析】`）**不是**关联；本规则默认标题与需求**完全同名**；若项目强制标题前缀，允许 `【分析】{需求标题}`，但仍须正式关联 + 正确标签。
## 幂等与查重
幂等键：
```text
项目ID + 需求ID + 阶段标签（分析|设计|交付/开发）
```
执行顺序：
1. 查询该需求下是否已有**未取消**、同阶段标签、同名（或同名前缀）任务。
2. **已存在一条** → 复用：核对正式关联、标签、负责人（待开发须为何斐）、时间字段；缺则补齐；**不新建第二条**。
3. **存在多条冲突** → 停止创建，列出任务编号，请人合并后再继续。
4. **不存在** → 创建并正式关联，再改需求状态（若口令是「推进到某状态」且任务尚未建好，先建任务再改状态，避免有状态无任务）。
快轨直接到 **待开发**（跳过分析/设计）：只建/复用 **待开发** 那一条同名任务（负责人何斐），不要为跳过的阶段补建分析/设计任务，除非用户明确要求。
## 与 OneOS 终态模型对齐
- `oneos_delivery`：待开发阶段的同名任务即唯一 **【交付】主任务**（标题优先与需求同名；标签=`交付`）。分析中/设计中另建同名阶段任务（标签分析/设计），**不**再额外建第二条交付主任务。
- `stage_tasks`：分析/设计/开发阶段任务按上表；待开发对应标签=`开发` 的同名任务，负责人何斐（若项目配置了其他默认开发负责人，以用户当次口令为准，口令未写则何斐）。
## AI 回报模板（短）
```text
需求：ONEOSP-xxx「标题」→ 状态：分析中/设计中/待开发
任务：TASK-xxx「同名」；标签：…；负责人：…；计划开始：…；已正式关联需求
查重：新建 / 复用
```
## 负向（不得误做）
- 需求仅到 `已确认` / `待处理`：不自动建分析/设计/待开发任务。
- 不得把样式类口头变更当成建任务触发。
- 不得在未查重时重复创建同阶段同名任务。
- 不得把负责人设错：分析中/设计中≠何斐（除非创建人就是何斐）；待开发必须何斐（除非用户当次明确改派）。

60
.cursor/skills/yunxiao-requirement-lifecycle/references/codeup-integration.md Normal file
View File

@@ -0,0 +1,60 @@
# Codeup研发资产集成
## 目录
1. 仓库覆盖
2. 分支策略
3. 正式关联
4. 提交与合并请求
5. CI01多仓库门禁
6. 验证场景
## 1. 仓库覆盖
前端、后端均可触发研发自动化，前提是仓库接入正确项目，分支/提交/MR正式关联需求，规则没有错误限定到单一仓库。
逐仓库记录：仓库名、角色、项目集成状态、Webhook、实际集成分支、是否纳入全部MR门禁和观察证据。
## 2. 分支策略
- 检查真实集成分支：存在`dev`则优先`dev`，否则使用存在的`develop`。
- 从集成分支创建`feature/<WORK-ITEM-ID>`或`fix/<WORK-ITEM-ID>`。
- 一个需求涉及多个仓库时，每个仓库可有一个同名活动分支。
- 快速迭代仍使用短生命周期分支；合并后是否删除按仓库策略和用户授权处理。
- 不直接推送保护分支，不为自动化方便创建不存在的`dev`/`develop`。
## 3. 正式关联
关联优先级：
1. 从需求“代码”区域创建分支并回到需求确认资产数量。
2. 在Codeup创建分支/MR时显式选择工作项；存在开发任务时同时关联需求和开发任务。
3. 使用以工作项ID结尾的分支名，并在需求页确认自动关联。
4. 提交说明关键字仅作兜底，必须回需求页验证。
需求编号、分支名或MR标题有关键字，不等同已正式关联。
## 4. 提交与合并请求
- 提交可带工作项ID增强追溯，但不判定开发完成。
- MR目标必须是仓库真实集成分支。
- MR显式关联需求和对应开发任务并完成评审。
- 只有全部相关MR合并后才观察R08。
- 首次提交时间不作为真实开发开始时间；人工“开始开发”为效能主口径。
## 5. CI01多仓库门禁
CI01要求所有相关前后端仓库的分支、提交和MR都正式关联需求与对应开发任务。只遗漏一个仓库或只关联需求，平台的“全部MR已合并”就可能只看到部分资产、提前完成需求，或完全无法完成开发任务。
如果无法可靠聚合所有仓库，保留人工核对门禁，不能声称R08已完全自动化。
## 6. 验证场景
| 场景 | 操作 | 期望 |
|---|---|---|
| 正式关联分支 | 从需求代码区创建真实仓库分支 | 异步进入开发中 |
| 非关联分支 | 仅本地创建/推送无关系分支 | 不触发R07 |
| 仅有提交 | 提交代码但不合并MR | 不进入开发完成 |
| 单仓库MR | 所有相关仓库只有一个MR合并 | 仍保持开发中 |
| 多仓库全部合并 | 所有相关MR正式关联并合并 | 进入开发完成 |
| 错误集成分支 | MR指向非真实集成分支 | 阻塞并修正，不伪造通过 |

103
.cursor/skills/yunxiao-requirement-lifecycle/references/lifecycle-rules.md Normal file
View File

@@ -0,0 +1,103 @@
# 需求生命周期与项目规则
## 目录
1. 状态参数化
2. R01–R12规则矩阵
3. 阶段入口和阶段完成
4. 开发开始与开发完成
5. 标签、任务和关键字
6. 规则实例与限制
## 1. 状态参数化
典型流程为：
```text
待处理 → 已确认 → 分析中 → 分析完成 → 设计中 → 设计完成 → 待开发
→ 开发中 → 开发完成 → 测试中 → 测试完成 → 完成发布/发布完成 → 已完成/已关闭
```
逐项目读取真实状态。`完成发布`与`发布完成`、`已完成`与`已关闭`是候选映射，不能静默互换或创建近义重复状态。
## 2. R01–R12规则矩阵
| ID | 流转 | 触发事件 | 必要条件 | 动作 | 方式 |
|---|---|---|---|---|---|
| R01 | 待处理 → 已确认 | 负责人确认 | 范围、负责人、优先级、验收口径明确 | 改为已确认 | 人工 |
| R02 | 已确认 → 分析中 | 添加关联任务工作项 | 当前状态；需求自身标签包含`分析` | 改为分析中 | 原生规则 |
| R03 | 分析中 → 分析完成 | 关联任务状态变化 | 当前状态；本阶段分析任务全部完成 | 改为分析完成 | 原生/条件化 |
| R04 | 分析完成 → 设计中 | 添加关联任务工作项 | 当前状态；需求自身标签包含`设计` | 改为设计中 | 原生规则 |
| R05 | 设计中 → 设计完成 | 关联任务状态变化 | 当前状态；本阶段设计任务全部完成 | 改为设计完成 | 原生/条件化 |
| R06 | 设计完成 → 待开发 | 添加关联任务工作项 | 当前状态；需求自身标签包含`开发` | 改为待开发 | 原生规则 |
| R07 | 待开发 → 开发中 | 添加关联分支或正式关联代码资产 | 当前状态；仓库已集成；资产正式关联 | 改为开发中 | 自动兜底 |
| R08 | 开发中 → 开发完成 | 关联合并请求状态变化 | 当前状态；全部相关MR已合并 | 改为开发完成 | 原生规则 |
| R09 | 开发完成 → 测试中 | 添加关联任务工作项 | 当前状态；需求自身标签包含`测试` | 改为测试中 | 原生规则 |
| R10 | 测试中 → 测试完成 | 测试验收任务或获批回调 | 当前状态；用例、失败复测、缺陷均闭环 | 改为测试完成 | 人工/桥接 |
| R11 | 测试完成 → 发布完成状态 | 发布变更完成或获批回调 | 当前状态；目标环境发布证据有效 | 改为真实发布状态 | 原生/桥接 |
| R12 | 发布完成状态 → 项目终态 | 业务验收 | 当前状态；验收证据有效 | 改为真实终态 | 默认人工 |
R05–R10与阶段任务自身状态的双向联动见`task-lifecycle.md`；R10的用例和缺陷口径见`test-defect-closure.md`；R11、R12见`pipeline-release.md`；R07、R08的代码资产口径见`codeup-integration.md`。
## 3. 阶段入口和阶段完成
R02、R04、R06、R09同时要求：
1. 从需求中“新建并关联”或“关联已有”任务工作项。
2. 当前状态等于前一阶段完成状态。
3. 需求自身包含目标阶段标签。
如果规则编辑器不能读取需求自身标签，标签只能用于筛选和报表；保留人工入口或使用当前状态+显式关联事件，不能声称标签已成为技术门槛。
R03、R05首选“本阶段任务全部完成”。若平台只能判断“全部关联任务工作项”，选择一种明确策略：
- 阶段开始时才创建/关联本阶段任务。
- 使用不同工作项类型，并确认规则能按类型过滤。
- 使用父子需求拆分阶段。
- 保留人工完成动作。
不得把零个关联任务当作全部完成。使用关联项状态变化触发，并执行零关联项负向测试。
## 4. 开发开始与开发完成
R07采用双轨口径：
- 效能主口径：开发人员真实开工时执行“开始开发”。
- 自动兜底：创建或正式关联需求分支/代码资产后进入`开发中`。
首次提交可能晚于真实开工，不能作为权威开始时间。自动规则必须要求当前状态=`待开发`。
R08推荐定义：
```text
事件 = 关联合并请求状态变化
且当前状态 = 开发中
且全部相关合并请求 = 已合并
则状态 = 开发完成
```
提交活动不能证明开发完成。全部相关前端、后端MR都必须正式关联并合并到实际集成分支。
## 5. 标签、任务和关键字
`分析`、`设计`、`开发`、`测试`标签加在产品类需求自身。
“添加关联任务工作项”依赖云效正式关系，不依赖标题关键字。有效方式：
- 在需求详情新建并关联任务。
- 在需求详情关联已有任务。
- 在任务详情选择该需求为父项/关联项，并在页面确认关系。
仅写需求编号、粘贴链接或添加同名标签都不能替代正式关联。编号仍建议出现在标题中，方便检索和审计。
## 6. 规则实例与限制
每个项目分别记录R01–R12的实际规则显示名/人工门禁、精确触发、源状态、目标状态、全部条件、动作、顺序、启用状态、执行账号和证据。
已知限制：
- 规则通常异步执行，5–30秒内不要过早判失败。
- “全部关联项”只能看到已集成并正式关联的资产。
- 提前创建未来阶段任务可能阻塞“全部任务完成”。
- 需求状态规则不会自动更新阶段任务状态；必须同时配置TK01–TK08。
- 平台能力因模板、版本和权限不同，以当前UI和执行日志为准。

133
.cursor/skills/yunxiao-requirement-lifecycle/references/live-operations.md Normal file
View File

@@ -0,0 +1,133 @@
# 线上实施、验证与治理
## 目录
1. 安全边界
2. 项目盘点
3. 规则应用
4. 隔离验证
5. 故障诊断
6. 回滚
7. 运行治理
## 1. 安全边界
- 只操作明确授权的组织、项目、工作项类型和测试资产。
- 复用已登录会话，不记录账号、密码、Cookie、Token、OTP、私钥或签名材料。
- 不修改现有prod流水线；回调实验只改test副本。
- 不删除测试需求、分支、MR、流水线或规则，除非另有授权。
- 保留无关规则和用户修改。
## 2. 项目盘点
先记录`flow_model=stage_tasks`或`flow_model=oneos_delivery`。发现两套规则同时启用时判定为迁移中，不按规则名称猜测主模型。
对每个项目独立记录：
| 类别 | 必查内容 |
|---|---|
| 项目 | 精确项目名、项目ID、工作项类型 |
| 工作流 | 全部状态、顺序、发布状态、终态 |
| 阶段任务 | 设计/开发/测试任务类型、状态、标签、父子/关联关系、自动创建能力 |
| 标签 | `分析`、`设计`、`开发`、`测试` |
| 规则 | 名称、事件、条件、动作、顺序、启用、执行账号、后继规则 |
| Codeup | 前后端仓库、集成、Webhook、真实`dev/develop` |
| 流水线 | test/prod名称、环境、部署阶段、副本能力 |
| 发布 | 发布变更关系、目标环境、完成状态 |
| 测试 | 计划范围、用例状态枚举、需求关系 |
| 缺陷 | 已修复、复测、关闭态、重开态、权限 |
两个项目只复制逻辑，不复制内部ID、仓库、分支、流水线、规则ID或观察证据。
OneOS终态迁移还要盘点：`待测试/发布中/发布失败`状态缺口、主任务身份方式、任务工作流方案A/B、原生规则能否过滤关联任务身份、Y/A控制负责人和幂等键。门禁未齐时保留可用旧规则，只停用会绕过验收或造成已确认误触发的规则。
## 3. 规则应用
1. 导出或截图现有规则和启用状态。
2. 识别后继规则和可能的连锁路径。
3. 创建缺失阶段标签。
4. 一次只创建或修改一条规则。
5. 设置精确触发、当前状态、需求标签、其他条件和目标动作。
6. 保存后重新打开，核对全部字段、顺序、启用状态和执行账号。
7. 把真实字段写回该项目`rule_instances`。
8. 触发最小事件，等待5–30秒。
9. 查看状态、研发资产、执行日志和二次流转。
10. 记录证据后再处理下一条。
手工推进只能标记为“测试准备动作”，不能伪造规则通过。
## 4. 隔离验证
测试需求命名示例：
```text
[自动化测试] 产品类需求生命周期验证-YYYYMMDD
```
| 用例 | 操作 | 期望 | 负向检查 |
|---|---|---|---|
| T01 | 已确认+分析标签+关联任务 | 分析中 | 无标签不流转 |
| T02 | 完成分析任务 | 分析完成 | 零任务不误触发 |
| T03 | 设计标签+关联任务 | 设计中 | 仅标题关键字不触发 |
| T04 | 完成设计任务 | 设计完成 | 未完成任务阻塞 |
| T04a | 设计完成后触发TK03 | 创建且只创建一个开发任务 | 重复事件不得重复创建 |
| T04b | 开发任务正式关联需求 | 需求待开发、任务待处理 | 仅标题编号不触发 |
| T05 | 开发标签+关联任务 | 待开发 | 错误当前状态不触发 |
| T06 | 正式关联真实仓库分支 | 开发中 | 非关联分支不触发 |
| T06a | 同一代码资产同时关联需求和开发任务 | 需求开发中、开发任务处理中 | 只关联需求不得声称任务已联动 |
| T07 | 前后端各关联MR，只合并一个 | 保持开发中 | 不得提前完成 |
| T08 | 全部相关MR合并 | 开发完成 | 仅提交不得完成 |
| T08a | 全部相关MR同时关联开发任务并合并 | 开发任务已完成 | 部分仓库MR未合并时阻塞 |
| T09 | 测试标签+关联测试任务 | 测试中 | 未来任务不应误阻塞 |
| T09a | test流水线部署成功触发TK07 | 创建且只创建一个测试任务并进入处理中 | 流水线失败或重复回调不得创建 |
| T10a | 执行全部用例并记录结果 | 每条有明确状态 | 未执行/阻塞/失败阻塞 |
| T10b | 失败用例关联缺陷，改为已修复 | 保持测试中 | 未复测不得完成 |
| T10c | 复测通过/失败 | 关闭并通过/重开并失败 | 用例缺陷状态一致 |
| T11 | 发布变更完成/获批回调 | 发布完成状态 | 重复回调不重复推进 |
| T12a | 进入发布完成后等待异步窗口 | 停留发布完成 | L01/L02不得误关闭 |
| T12b | 完成正式业务验收 | 项目终态 | test或发布不能替代验收 |
结果只使用：`通过`、`异步通过`、`未触发`、`误触发`、`阻塞`。
## 5. 故障诊断
按顺序检查：
1. 事件是否真实发生，而不是只有相似标题/标签。
2. 当前状态是否精确匹配。
3. 标签是否加在需求自身。
4. 任务、分支、MR、发布变更是否正式关联。
5. 仓库是否接入正确项目，Webhook是否有效。
6. 全部相关MR是否合并到真实集成分支。
7. 规则是否启用，执行账号是否有权限。
8. 执行日志是未匹配、失败还是排队。
9. 用例是否仍有未执行、阻塞或失败。
10. 缺陷是否仅到已修复，尚未复测关闭。
11. 目标状态是否触发后继/重复规则。
12. 是否发生`测试完成 → 发布完成 → 终态`瞬时连锁。
13. 是否等待合理异步窗口。
14. 是否误用另一个项目的内部ID或证据。
15. 缺陷与原用例在复测后的状态是否一致。
16. 需求状态变化是否遗漏对应阶段任务状态，或任务变化是否遗漏需求汇总。
17. 自动创建下一阶段任务是否具有需求ID+阶段类型幂等门禁。
18. 项目是否混用R/TK阶段模型与Y/A终态模型。
19. OneOS主任务是否唯一且可被规则可靠识别。
20. 是否缺少`待测试`、`发布中`、`发布失败`或重试流转边。
## 6. 回滚
- 先禁用本次新增规则，再恢复修改前条件和动作。
- 保留变更前截图/导出和规则ID。
- 回调POC通过禁用副本回滚；删除需单独授权。
- 分支/MR等测试资产按仓库策略清理；删除需单独授权。
- 不覆盖与本次变更无关的规则。
## 7. 运行治理
- 每季度复核规则账号、权限、启用状态和失败日志。
- 新增仓库时同步验证项目集成、Webhook和多仓库门禁。
- 状态、标签或工作项类型重命名后逐条复核依赖规则。
- 保护`master/main`和真实`dev/develop`。
- 监控超过7天无活动的需求分支，未经授权不删除。
- 分开统计自动流转时间与真实业务开始时间。
- 持续检查回调签名、时间戳、防重放、幂等和失败重试。

117
.cursor/skills/yunxiao-requirement-lifecycle/references/oneos-pc-fast-path.md Normal file
View File

@@ -0,0 +1,117 @@
# 统一运营管理平台 · 记录需求快路径
真相源运行时 ID：[assets/oneos-pc-runtime-ids.json](../assets/oneos-pc-runtime-ids.json)
验证样例：ONEOS-84「测试需求」（2026-07-21）。
**用户可复制完整口令（A/B/C 门禁 + 30 标签）：** [oneos-pc-record-requirement-prompt.md](oneos-pc-record-requirement-prompt.md)
本文件只服务**日常 `记录需求` apply**。全量审计/规则配置仍读 `live-operations.md` 等模块。
## 0. 执行门禁（强制）
用户口令要求 Plan / 单选「优先级」「推进至」「标签」时：
1. **必须**先拿到明确的 A（紧急/高/中/低）、B（分析中/设计中/设计完成/开发中）、**C（标签，可多选）**。
2. 标签 **C** 只能从 [assets/oneos-pc-tag-catalog.md](../assets/oneos-pc-tag-catalog.md) / `tags.catalog` 点选；**禁止**按 `lines.ts` 或业务条线说明自动推断。
3. 来源优先：`AskQuestion` 点选 → Plan 批准时写明的 A+B+C → 用户一句话点明。
4. **禁止**：未选时默认「中 + 分析中」并继续建单；**禁止**未选标签时自作主张打标。
5. 「批准/Implement 计划」≠ 已选 A+B+C；计划正文若仍是空 ○，必须先问清再执行。
多条需求名称时：每条或整批共用的优先级/推进至/标签仍须用户点选后再写云效。
## 1. 加载配方（禁止重探）
对项目别名含「统一运营管理平台」时：
1. 读取 `assets/oneos-pc-runtime-ids.json`。
2. **禁止**再探测 create URL（不要用 `/workitem/create`）。
3. **禁止**对优先级 ID 做猜测重试超过配方表。
## 2. 标准执行顺序（目标 1～3 分钟）
```text
AutoPRD → API 建需求(含描述) → API 建阶段任务 → API 打标签(COVER) → 状态连跳 → 一次校验回报
```
### 2.1 AutoPRD
- 先跑 `$oneos-autoprd`（模块/原型来自口令或对话页）。
- 描述 HTML 最小块：`【原型】` + `【目标】` + `【非目标】` + `【更新内容】`（无变更记录则「首版定稿」）。
### 2.2 API 建产品类需求
`POST`（失败再试一次 `PUT`）
`https://devops.aliyun.com/projex/api/workitem/workitem?_input_charset=utf-8`
要点：
- `workitemTypeIdentifier` **与** `workitemType` 都设为产品类需求 ID。
- `document: { content: html, formatType: 'RICHTEXT' }` 创建时写入。
- `fieldValueList` 带 `priority`、`assignedTo`、可选 `79`（计划开始，中国时区中午 epoch 字符串）。
- 开发中：需求负责人用何斐 ID；分析中/设计中/设计完成：创建人 ID。
### 2.3 API 建同名阶段任务
同一 create 接口，`category=Task`，`parentIdentifier=需求ID`，标题与需求**完全同名**。
| 推进至 | 任务标签目标 | 负责人 |
|---|---|---|
| 分析中 | 分析 | 创建人 |
| 设计中 | 设计 | 创建人 |
| 开发中 / 待开发 | 开发或交付 | 何斐 |
查重：同需求 + 同阶段标签 + 未取消 → 复用，不建第二条。详见 [auto-stage-task.md](auto-stage-task.md)。
### 2.4 状态连跳（开发中）
从「待处理」到「开发中」UI 固定路径：
```text
待处理 → 设计完成 → 待开发 → 开发中
```
每跳点开状态按钮选目标；不要在「待处理」下拉里找「开发中」（没有）。
其它推进至：
- 分析中 / 设计中 / 设计完成：待处理下拉通常可直达。
### 2.5 标签（选择器点选 + API）
1. 用户已从 `tags.catalog` 点选标签名（见门禁 C）；用 `tags.by_name` 得到 identifier。
2. **优先 API**（已验证）：
```http
PATCH https://devops.aliyun.com/projex/api/workitem/workitem/{identifier}?_input_charset=utf-8
Content-Type: application/json
{
"workitemIdentifier": "{identifier}",
"propertyKey": "tag",
"propertyValue": "{id1,id2}",
"operateType": "COVER"
}
```
3. API 失败 1 次 → UI 标签选择器勾选 → **确定**；仍失败 → **停止并请用户回复标签名**，禁止报「已打上」。
4. **禁止**对照 `lines.ts` / 业务条线说明自动映射；刷新全量标签：`GET` `api.list_tags`（`spaceType=Space`）。
### 2.6 校验与回报（只做一次）
核对：编号、链接、状态、优先级、负责人、计划开始、描述含原型、任务父项、标签。
截图最多：建单后、终态后各一次。
## 3. 性能红线
| 允许 | 禁止 |
|---|---|
| 配方内 ID / URL | 每步 3+ 端点盲探 |
| create 带描述 | 默认先开富文本再粘贴 |
| 状态固定三跳 | React fiber 乱调 onChange（易白屏） |
| 标签失败问用户 | 标签失败仍声称成功 |
| API 失败 1 次改 UI | 同失败 payload 循环重试 |
## 4. 浏览器会话
- 复用已登录 `devops.aliyun.com`；不记录 Cookie/Token。
- 优先已打开的「统一运营管理平台」项目页；锁 tab 后执行，结束解锁。

139
.cursor/skills/yunxiao-requirement-lifecycle/references/oneos-pc-record-requirement-prompt.md Normal file
View File

@@ -0,0 +1,139 @@
# 统一运营管理平台 · 记录需求到云效（完整提示词）
复制下方「用户口令」整段发给 Agent；Agent 须先弹出 Plan / 单选卡让你点选 **A 优先级 + B 推进至 + C 标签**，**未点选前不得建单**。
---
## 用户口令（复制整段）
```text
使用 $yunxiao-requirement-lifecycle + $oneos-autoprd
记录需求到云效 · 统一运营管理平台
【需求名】
（填写 1 条或多条，例：车辆资产功能优化）
【描述来源】
$oneos-autoprd，原型/模块：（填写，例：oneos-h5-vehicle-assets）
【已锁定】
- 项目：统一运营管理平台
- 计划开始：今日
- 负责人：分析中 / 设计中 / 设计完成 → 创建人；开发中 → 何斐
【请你先 Plan 点选，未选完禁止写云效】
A. 优先级（单选）
○ 紧急
○ 高
○ 中
○ 低
B. 推进至（单选）
○ 分析中（建同名「分析」任务，负责人=创建人）
○ 设计中（建同名「设计」任务，负责人=创建人）
○ 设计完成（只改状态，负责人=创建人；不强制建阶段任务）
○ 开发中（建同名开发/交付任务，负责人=何斐；状态连跳：待处理→设计完成→待开发→开发中）
C. 标签（可多选；只能从下列 30 个云效标签中选，禁止自造、禁止按业务条线/lines.ts 自动推断）
○ 运维管理条线
○ 报表中心
○ 能源管理
○ 维修站管理
○ 充电站管理
○ 还车应结款
○ 交车应收款
○ 加氢站管理
○ 保险管理
○ 合同管理
○ 租赁账单
○ 供应商管理
○ 客户管理
○ 还车任务
○ 安全培训
○ 备件管理
○ 停车场管理
○ 备车管理
○ 异动管理
○ 调拨管理
○ 上牌管理
○ 替换车管理
○ 还车管理
○ 交车管理
○ 车辆管理
○ 审批中心
○ 故障管理
○ 车辆年审
○ 维修管理
○ 工作台
【我确认 A+B+C 后你再执行】
批准 / Implement 计划时，我会写明所选值，例如：
优先级：高；推进至：设计完成；标签：运维管理条线
【执行要求（Agent）】
1. 读快路径：references/oneos-pc-fast-path.md + assets/oneos-pc-runtime-ids.json
2. 先 $oneos-autoprd 生成描述（【原型】【目标】【非目标】【更新内容】；无增量则「首版定稿」）
3. API 建产品类需求（POST /workitem/workitem，创建时写入 document）
4. 计划开始=今日；按 B 推进状态；按规则建/复用同名阶段任务
5. 标签：用 tags.by_name 查 identifier，PATCH propertyKey=tag operateType=COVER；API 失败 1 次再 UI 兜底
6. 一次校验回报：编号、链接、状态、优先级、负责人、计划开始、标签、描述、阶段任务
7. 禁止默认「中+分析中」；禁止未选标签时自作主张打标；标签失败不得报「已成功」
```
---
## 单条需求示例（填好即用）
```text
使用 $yunxiao-requirement-lifecycle + $oneos-autoprd
记录需求到云效 · 统一运营管理平台
【需求名】
测试需求3
【描述来源】
$oneos-autoprd，原型/模块：oneos-h5-vehicle-assets
【已锁定】
- 项目：统一运营管理平台
- 计划开始：今日
- 负责人：分析中/设计中/设计完成=创建人；开发中=何斐
请先 Plan 让我点选 A 优先级、B 推进至、C 标签（30 项 catalog，禁止 lines.ts 推断）。
我确认后再执行快路径建单。
```
确认回复示例：
```text
优先级：高；推进至：设计完成；标签：运维管理条线
```
---
## Agent 执行清单（内部，勿省略）
| 步 | 动作 |
|---|---|
| 0 | 门禁：A+B+C 已明确；Implement ≠ 已选 |
| 1 | `$oneos-autoprd` → HTML 描述 |
| 2 | `POST …/workitem/workitem` 建需求 + document |
| 3 | 字段：priority、assignedTo、79=今日 |
| 4 | 若 B∈{分析中,设计中,开发中} → 同名阶段任务（查重复用） |
| 5 | 状态推进至 B（开发中三跳） |
| 6 | `PATCH …/workitem/{id}` 打标签 COVER |
| 7 | 回报 ONEOS-xxx + 链接 + 核对表 |
标签 API 形态：
```json
{
"workitemIdentifier": "{id}",
"propertyKey": "tag",
"propertyValue": "{identifier1},{identifier2}",
"operateType": "COVER"
}
```
参考：`assets/oneos-pc-tag-catalog.md`、`assets/oneos-pc-runtime-ids.json` → `tags.by_name`

192
.cursor/skills/yunxiao-requirement-lifecycle/references/oneos-terminal-flow.md Normal file
View File

@@ -0,0 +1,192 @@
# OneOS终态交付模型与迁移规则
## 目录
1. 模型选择与边界
2. 工作项和状态
3. 原生Y规则
4. AI与Webhook桥接
5. 迁移就绪门禁
6. 分阶段实施
7. 验收与负向测试
8. 已知风险和回滚
## 1. 模型选择与边界
OneOS终态模型以需求为阶段看板唯一真相：
```text
迭代
├─ 多个产品类需求
├─ 按需求分包的测试计划
└─ 一条【发版】任务
产品类需求
└─ 一条【交付】主任务
├─ 多条【开发】任务
└─ 一条【测试】任务
```
每个项目只能选择一个主模型：
- `stage_tasks`：分析、设计、开发、测试各建阶段任务，使用R/TK控制。
- `oneos_delivery`：一条交付主任务镜像需求，多开发任务汇总，使用Y/A控制。
不得同时启用两套进场规则。若项目仍有分析/设计标签驱动的R规则，先记录为`legacy_active`，完成迁移就绪检查后再停用。
## 2. 工作项和状态
### 2.1 任务身份
| 任务 | 数量 | 必须关系 | 识别优先级 |
|---|---:|---|---|
| `【交付】`主任务 | 每需求1条 | 正式关联需求 | 独立工作项类型 > 任务标签`交付` > 标题前缀流程约束 |
| `【开发】`任务 | 每需求1..N条 | 正式关联需求和主任务 | 独立类型 > 标签`开发` > 标题前缀 |
| `【测试】`任务 | 每需求1条 | 正式关联需求和主任务 | 独立类型 > 标签`测试` > 标题前缀 |
| `【发版】`任务 | 每迭代1条 | 正式关联迭代和本批需求 | 独立类型 > 标签`发版` > 标题前缀 |
标题关键字本身不构成正式关系。规则编辑器不能读取关联任务的类型、标签或标题时，不得声称原生规则能区分主任务和开发任务；使用桥接或人工门禁。
### 2.2 需求状态
目标状态顺序：
```text
待处理 → 已确认 → 分析中 → 分析完成 → 设计中 → 设计完成
→ 待开发 → 开发中 → 开发完成 → 待测试 → 测试中 → 测试完成
→ 发布中 → 发布完成 / 发布失败 → 已关闭
```
允许的快轨至少包括`已确认 → 待开发`和`设计完成 → 待开发`。`发布失败 → 发布中`用于重试。已有近义状态先映射，禁止静默创建`完成发布/发布完成`、`已完成/已关闭`等重复状态。
### 2.3 任务状态
- 主任务：首选与需求同名镜像状态。
- 开发任务：`待处理 → 处理中 → 已完成`，另有取消态。
- 测试任务：`待处理/待测试 → 测试中 → 已完成`。
- 发版任务：`待处理 → 发布中 → 发布完成/发布失败`。
若任务工作流不能承载主任务全量状态，不配置Y02–Y16原生镜像；由桥接更新需求并记录主任务显示口径。
## 3. 原生Y规则
统一规则前缀：`[OneOS终态] Yxx ...`。保存后重新打开核对事件、条件、动作、顺序、启用状态和执行账号。
### 3.1 主任务镜像
| ID | 触发 | 条件 | 动作 | 默认方式 |
|---|---|---|---|---|
| Y01 | 新增正式关联主任务 | 主任务可可靠识别；需求为待处理/已确认 | 需求与主任务进入分析中或获批快轨 | 原生/桥接 |
| Y02 | 主任务到分析完成 | 正式关联唯一需求 | 需求到分析完成 | 原生 |
| Y03 | 主任务到设计中 | 正式关联唯一需求 | 需求到设计中 | 原生 |
| Y04 | 主任务到设计完成 | 正式关联唯一需求 | 需求到设计完成 | 原生 |
| Y05 | 主任务到待开发 | 正式关联唯一需求 | 需求到待开发；负责人按项目配置 | 原生/桥接 |
| Y06 | 主任务到开发中 | 正式关联唯一需求 | 需求到开发中 | 原生 |
| Y07 | 主任务到开发完成 | 正式关联唯一需求 | 需求到开发完成 | 原生 |
| Y08 | 主任务到待测试 | 正式关联唯一需求 | 需求到待测试 | 原生 |
| Y09 | 主任务到测试中 | 正式关联唯一需求 | 需求到测试中 | 原生 |
| Y10 | 主任务到测试完成 | Testhub门禁通过 | 需求到测试完成 | 桥接优先 |
| Y11 | 主任务到发布中 | 发版任务和迭代范围有效 | 需求到发布中 | 原生/桥接 |
| Y12 | 主任务到发布完成 | 生产发布证据有效 | 需求到发布完成 | 桥接 |
| Y13 | 主任务到发布失败 | 生产发布失败证据有效 | 需求到发布失败并记录原因 | 桥接 |
| Y14 | 主任务到已关闭 | 产品验收证据有效 | 需求到已关闭 | 默认人工 |
| Y15 | 需求状态变化 | 存在唯一主任务且无循环风险 | 主任务同名镜像 | 可选原生 |
| Y16 | 需求快轨到待开发 | 存在唯一主任务 | 主任务到待开发 | 原生/桥接 |
每条双向镜像规则必须有防循环条件。平台无法区分“由本规则写入”的事件时，只保留一个权威方向。
### 3.2 开发任务汇总
| ID | 触发 | 条件 | 动作 | 默认方式 |
|---|---|---|---|---|
| Y20 | 新增第一条开发任务或正式关联开发分支 | 需求=待开发；开发任务数量≥1；任务已指派 | 需求和主任务到开发中；对应开发任务处理中 | 原生/桥接 |
| Y21 | 开发任务完成 | 非取消开发任务数量≥1且全部完成；全部相关MR已合并 | 需求和主任务到开发完成 | 桥接优先 |
| Y22 | 开发完成 | 同需求无未取消测试任务；幂等键未处理 | 创建并关联唯一测试任务，进入待测试 | 桥接 |
现有的“任务添加分支且标签=开发，待处理→处理中”和“全部MR已合并且标签=开发，处理中→已完成”可作为Y20/Y21的任务侧子规则保留。需求侧“全部MR已合并”只能看到正式关联资产，必须执行多仓库负向测试。
### 3.3 测试、发布和迭代
| ID | 触发 | 条件 | 动作 | 默认方式 |
|---|---|---|---|---|
| Y30 | 创建测试任务 | 正式关联需求和主任务 | 需求/主任务到待测试 | 桥接 |
| Y31 | 首条用例执行或测试负责人开工 | 测试任务=待处理/待测试 | 测试任务、需求、主任务到测试中 | 原生/人工 |
| Y32 | 测试验收完成 | 本需求用例包全部通过且缺陷闭环 | 三个对象完成测试阶段 | 桥接/人工 |
| Y33 | 发版任务提交 | 发版任务正式关联迭代与本批需求 | 发版任务和本批需求到发布中 | 原生/桥接 |
| Y34 | 生产发布成功 | 流水线执行、环境、范围、签名和幂等均有效 | 到发布完成 | 桥接 |
| Y35 | 生产发布失败 | 同上；失败证据有效 | 到发布失败并记录原因 | 桥接 |
| Y40 | 需求到待开发 | 未关联迭代 | 通知产品负责人，不自动写入未知迭代 | 通知/人工 |
test部署只能允许测试开始，不能触发Y34。发布完成后必须停留，等待产品/业务验收；禁止自动进入已关闭。
## 4. AI与Webhook桥接
| ID | 能力 | 最小门禁 |
|---|---|---|
| A01 | 发布原型/附件并回写需求描述 | 外部存储授权；链接可审计 |
| A02 | 生成并保留更新内容历史 | 不覆盖历史段；**OneOS 默认调用 `$oneos-autoprd` 第 10 章「功能变更记录」（自上次定稿以来）；旧段挪到「更新内容·历史」** |
| A02B | 生成产品可读需求说明 | 不写实现机密；保留来源；**OneOS 默认调用 `$oneos-autoprd` 全文/交付口径写入「需求说明」** |
| A03 | 建需求和唯一主任务并快轨待开发 | 幂等查询；正式关系可见；**建单写描述前先完成 A02+A02B（AutoPRD）**；进入待开发时按 [auto-stage-task.md](auto-stage-task.md) 建/复用与需求同名任务，负责人何斐，时间沿用需求 |
| A03B | 需求进入分析中/设计中自动建同名阶段任务 | 标签分析/设计；负责人=需求创建人；正式关联；时间沿用需求；与 A03 同一套查重 |
| A04 | 拆分多条开发任务 | 负责人、范围和父子关系明确 |
| A05 | 按MR证据关闭开发任务 | 所有仓库、目标分支和关联关系完整 |
| A06 | 全部开发完成后建唯一测试任务 | 幂等键=`项目ID+需求ID+create_test_task` |
| A07 | 按Testhub结果完成测试 | 用例与缺陷口径满足TC/DF控制 |
| A08 | 按迭代创建发版任务和更新说明 | 正式关联迭代和本批需求 |
| A09 | 发布成败回写 | 验证环境、签名、时间戳、执行ID和范围 |
| A10 | 产品验收后关闭 | 明确验收人和证据；不得由发布成功替代 |
所有桥接必须具备：最小权限服务账号、签名、时间戳、防重放、幂等、失败重试、审计日志和人工回退。不得把未部署的AI能力写成已自动化。
## 5. 迁移就绪门禁
只有全部满足时才停用旧R/TK进场规则：
1. 需求状态已包含`待测试`、`发布中`、`发布失败`，并配置必要流转边。
2. 主任务能被可靠识别；若只能靠标题前缀，已明确由桥接处理，不使用无过滤原生镜像。
3. 主任务和开发/测试/发版任务的工作流已选定并验证。
4. Y/A控制逐项指定`native_rule`、`integration_bridge`、`manual`或`not_supported`。
5. A03、A06、A08、A09具备幂等键、负责人和回退方案。
6. Codeup前后端仓库、真实`dev/develop`、正式关联和多仓库MR门禁已验证。
7. Testhub按需求分包；未执行、阻塞、失败用例和仅“已修复”缺陷会阻塞测试完成。
8. test、生产发布、发布变更和产品验收证据已分离。
9. 已保存旧规则名称、条件、顺序、启用状态和执行账号证据。
10. `L01`、`L02`已停用，发布完成不会瞬时关闭。
未通过门禁时：保留当前可用规则，只停用会绕过验收或造成误触发的规则，并输出迁移计划。
## 6. 分阶段实施
- P0：补齐工作流、唯一主任务、快轨待开发、负责人和旧规则备份。
- P1：开发任务拆分、分支/MR双关联、多仓库完成门禁、唯一测试任务。
- P2：迭代、Testhub按需求分包、用例和缺陷复测闭环。
- P3：发版任务、生产流水线成败回写、发布失败重试、产品验收关闭。
每阶段先在隔离测试需求验证，再启用下一阶段。新规则不补触发历史事件；历史数据修正必须单独记录。
## 7. 验收与负向测试
| ID | 操作 | 期望 | 负向检查 |
|---|---|---|---|
| V01 | 创建需求和唯一主任务 | 正式关联且不重复 | 重放不得建第二条主任务 |
| V02 | 未建开发任务 | 保持待开发 | 主任务本身不得被当作开发任务 |
| V03 | 建两条开发任务 | 进入开发中 | 无正式关系或无负责人不触发 |
| V04 | 只完成一条开发任务/MR | 保持开发中 | 不得提前完成 |
| V05 | 所有开发任务和MR完成 | 开发完成并只建一条测试任务 | 重复回调不重复创建 |
| V06 | 同迭代其他需求未测完 | 本需求仍可独立完成测试 | 不按整个计划全绿判断 |
| V07 | 用例失败且缺陷仅已修复 | 保持测试中 | 未复测不得完成 |
| V08 | 复测通过/失败 | 用例通过+缺陷关闭 / 用例失败+缺陷重开 | 双方状态必须一致 |
| V09 | test部署成功 | 允许测试开始 | 不得发布完成 |
| V10 | 生产发布成功 | 发布完成并停留 | 不得自动已关闭 |
| V11 | 生产发布失败后重试 | 发布失败→发布中 | 原因和执行ID可审计 |
| V12 | 产品验收 | 已关闭 | 无验收证据不关闭 |
## 8. 已知风险和回滚
- “全部关联任务完成”若无法按任务身份过滤，会把主任务或测试任务纳入，默认交桥接。
- 仅标题前缀不能替代正式关系，也不能保证原生规则可过滤。
- 需求和主任务双向镜像可能循环，只保留一个权威方向或增加来源防重。
- 分支/MR只关联需求而未关联开发任务，会导致任务状态不更新。
- 发布完成自动关闭会绕过产品验收；`L01`、`L02`默认停用。
回滚顺序：先禁用本次新增Y/A入口，恢复旧规则启用状态和顺序，再恢复状态流转边；保留已创建任务、关系和执行日志，删除任何资产需单独授权。

66
.cursor/skills/yunxiao-requirement-lifecycle/references/pipeline-release.md Normal file
View File

@@ -0,0 +1,66 @@
# 流水线、发布与最终验收
## 目录
1. 环境证据边界
2. R11发布完成
3. CI02回调POC
4. CI03证据分离
5. R12最终验收
6. L01–L02历史规则
7. 连锁触发验证
## 1. 环境证据边界
分别记录以下事件，未经批准不得互相替代：
- test环境部署成功。
- 生产环境流水线发布成功。
- 云效关联发布变更达到完成状态。
- 产品/业务验收完成。
流水线成功不等于测试用例通过，test成功也不默认等于生产发布完成。
## 2. R11发布完成
优先使用“关联发布变更达到项目真实完成状态”作为R11证据。规则要求当前状态=`测试完成`，目标环境和发布证据满足组织口径。
如果组织明确把test部署定义为“完成发布”，必须记录该口径的批准证据；否则test回调只记录测试部署成功，不推进发布完成。
## 3. CI02回调POC
1. 复制现有test流水线并使用明显POC名称。
2. 保留原test与prod流水线不变。
3. 只在副本Docker部署成功路径末尾添加回调。
4. 普通变量传工作项ID、环境、流水线执行ID。
5. 密钥变量保存认证材料，不写入仓库、命令输出或文档。
6. 请求携带时间戳、签名和执行ID幂等键。
7. 服务端校验需求当前状态，只允许预期流转执行一次。
8. 测试成功、重复回调、错误签名、超时、部署失败和安全重试。
9. POC通过后走推广评审，不直接修改prod。
## 4. CI03证据分离
CI03要求项目配置分别保存test、prod、发布变更和验收证据。任何桥接都必须记录实现方式、启用状态、负责人、证据和人工回退。
回调失败保留失败日志并可安全重试，不得伪造成功。同一执行ID重试不得多次推进需求。
## 5. R12最终验收
发布成功不等于业务验收。默认由产品/业务负责人确认后人工进入`已完成`或`已关闭`。只有可靠、可审计的验收任务才允许条件化自动关闭。
## 6. L01–L02历史规则
- `L01`：`发布完成 + 全部关联任务完成/关闭 → 项目终态`。默认停用或收紧为独立验收任务，避免早期阶段任务误满足。
- `L02`：监听`测试完成 → 发布完成`状态路径并立即进入项目终态。默认停用，防止发布完成成为瞬时状态。
逐项目记录两条规则是否存在、是否启用、真实条件、顺序和证据；不存在也要有盘点证据。
## 7. 连锁触发验证
- 不按规则名称推断行为，逐条读取触发、条件、动作、顺序和执行账号。
- 每个目标状态都检查后继规则和重复规则。
- R11后至少观察两个时点：刚进入发布完成时，以及等待5–30秒后。
- 未经验收自动进入终态时，记录实际后继规则并判定`误触发`。
- 跨两级以上流转必须有独立负向测试，不能只验证最终状态。

97
.cursor/skills/yunxiao-requirement-lifecycle/references/report-template.md Normal file
View File

@@ -0,0 +1,97 @@
# 云效自动化执行报告模板
```markdown
# 云效产品需求全生命周期自动化执行报告
## 1. 基本信息
- 组织：
- 项目：
- 工作项类型：
- 流程模型：stage_tasks / oneos_delivery
- 迁移阶段（仅oneos_delivery）：P0 / P1 / P2 / P3
- 执行模式：audit / plan / apply / test / document
- 执行时间：
- 执行账号：仅记录显示名，不记录凭据
## 2. 观察到的当前配置
| 项目 | 生命周期 | 标签 | 仓库/集成分支 | test流水线 | 发布证据 |
|---|---|---|---|---|---|
## 3. 规则变更
| 项目 | 规则 | 变更前 | 变更后 | 启用状态 | 复开核验 |
|---|---|---|---|---|---|
### 3.0 项目级规则实例
| 项目 | 规则ID | 云效规则显示名/人工门禁 | 精确触发事件 | 源状态 | 必要条件 | 动作/目标状态 | 顺序 | 启用 | 观察证据 |
|---|---|---|---|---|---|---|---:|---|---|
每个项目必须分别覆盖`R01`–`R12`和`TK01`–`TK08`。不得把一个项目的规则ID、显示名、顺序或证据复制为另一个项目的观察结果。
### 3.1 完整性台账
| 控制ID | 对象/流转 | 实现方式 | 启用状态 | 观察证据 | 负责人 | 回退方案 | 结论 |
|---|---|---|---|---|---|---|---|
每个项目必须分别覆盖全部31项：`R01`–`R12`、`TK01`–`TK08`、`TC01`–`TC03`、`DF01`–`DF03`、`CI01`–`CI03`、`L01`–`L02`。不得把“规则编辑器不支持”写成“已完成”；应记录为`not_supported`并给出人工门禁或集成桥接方案。
`oneos_delivery`模型改用48项台账：`Y01`–`Y16`、`Y20`–`Y22`、`Y30`–`Y35`、`Y40`、`A01`、`A02`、`A02B`、`A03`–`A10`、`TC01`–`TC03`、`DF01`–`DF03`、`CI01`–`CI03`、`L01`–`L02`。
### 3.1a OneOS迁移就绪度
| 项目 | 目标状态缺口 | 主任务身份方式 | 原生规则能否过滤 | 任务工作流方案 | 桥接幂等/负责人 | 旧规则处置 | 结论 |
|---|---|---|---|---|---|---|---|
旧R/TK规则只有在目标状态、任务身份、任务工作流、桥接和回滚证据全部就绪后才能停用。`L01`、`L02`不受此等待条件影响，应保持停用以保护产品验收。
### 3.2 规则顺序与连锁触发
| 前置规则 | 目标状态 | 后继规则 | 是否自动二次流转 | 是否绕过验收 | 处理结论 |
|---|---|---|---|---|---|
## 4. 验证结果
| 用例 | 触发事件 | 期望状态 | 实际状态 | 结果分类 | 执行日志/证据 |
|---|---|---|---|---|---|
## 5. 研发资产覆盖
| 仓库 | dev/develop | 分支关联 | 提交关联 | MR关联 | 全部合并判断 |
|---|---|---|---|---|---|
## 6. 流水线与发布
| 流水线 | 环境 | 是否副本 | Docker部署 | 回调 | 是否影响prod |
|---|---|---|---|---|---|
## 7. 测试计划与缺陷闭环
| 测试计划 | 用例总数 | 已通过 | 未执行/待测试 | 阻塞 | 未通过 | 结论 |
|---|---:|---:|---:|---:|---:|---|
| 缺陷 | 关联用例/需求 | 修复状态 | 复测结果 | 最终状态 | 证据 |
|---|---|---|---|---|---|
| 失败用例 | 关联缺陷 | 缺陷已修复后用例状态 | 复测通过后用例状态 | 复测失败后用例状态 | 证据 |
|---|---|---|---|---|---|
## 8. 人工节点与剩余风险
- 真实开发开始时间：
- 业务验收：
- 发布完成是否被后继规则立即关闭：
- 全部关联任务范围：
- 多仓库漏关联风险：
- 其他：
- 范围外通用自动化（通知、指派、SLA、字段同步等）：
## 9. 回滚
- 禁用新增规则：
- 恢复旧规则：
- 停用回调POC：
- 测试资产清理（需授权）：
```

499
.cursor/skills/yunxiao-requirement-lifecycle/references/role-trigger-prompts.md Normal file
View File

@@ -0,0 +1,499 @@
# 云效全流程角色与触发节点沟通话术
> 本文是异常处理和精细交接使用的详细版。日常操作优先读取`simple-role-commands.md`，使用“记录需求、开始分析、开始开发、提交测试、测试完成、发布成功、验收通过”等短口令。
## 目录
1. 使用规则
2. 通用话术骨架
3. 项目管理员与流程负责人
4. 产品负责人
5. 需求分析人员
6. 设计人员
7. 交付负责人
8. 技术负责人
9. 开发人员
10. 代码评审人员
11. 测试负责人和测试人员
12. 缺陷修复人员
13. 运维与发布负责人
14. 业务验收人员
15. 集成桥接负责人
16. 异常和催办话术
17. 节点交接清单
## 1. 使用规则
这套话术用于让不同角色把真实业务事件准确告诉Codex，再由Codex审计、规划、执行获批修改、验证或形成报告。默认使用`yunxiao-requirement-lifecycle`。
每次沟通至少提供：
- 精确项目名和需求编号。
- 当前角色、当前状态和刚刚发生的真实事件。
- 关联任务、仓库、分支、MR、测试计划、缺陷或流水线执行ID；没有就明确写“无”。
- 希望Codex采用的权限：`audit`、`plan`、`apply`、`test`或`document`。
- 期望停在哪个状态，不要只说“继续流转”。
权限含义：
- `audit`：只核查和报告，不修改云效。
- `plan`：只输出修改方案和影响，不执行。
- `apply`：只修改话术中明确列出的项目、工作项或规则。
- `test`：使用隔离测试资产触发并收集证据。
- `document`：只形成说明、记录或报告。
必须遵守：
- 标题、需求编号、分支名或标签不能代替云效正式关联。
- 首次提交不代表真实开始开发；人工“开始处理”是效能主口径，分支关联只是自动兜底。
- `已修复`只表示交给测试复测，不是缺陷关闭。
- test部署成功不等于测试通过，更不等于生产发布完成。
- 发布成功后停留`发布完成`，必须有产品或业务验收才能进入`已关闭`。
- 未明确授权时，不改生产流水线、不直接推送保护分支、不删除规则或测试资产。
- 项目仍为`stage_tasks`时使用R/TK规则；只有迁移门禁通过后才使用完整`oneos_delivery`链路。
## 2. 通用话术骨架
### 2.1 请求执行
```text
使用 yunxiao-requirement-lifecycle。
权限：【audit/plan/apply/test/document】
项目：【精确项目名】
流程模型：【未知/stage_tasks/oneos_delivery】
我的角色：【角色】
需求：【需求编号+标题】
当前状态：【状态】
刚发生的事件：【真实事件】
相关资产：【任务/MR/分支/测试计划/缺陷/流水线执行ID；没有写无】
期望结果：【目标状态或需要生成的资产】
请先核查当前状态和正式关联，再执行授权范围内动作；输出实际动作、触发结果、证据、未完成项和下一责任人。不要用手工改状态冒充自动化通过。
```
### 2.2 只核查为什么没有流转
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
项目：【项目名】，需求：【编号】，当前状态：【状态】。
我已执行：【事件】，相关对象：【对象编号或链接】；等待了【秒数】仍未流转。
请按事件、当前状态、标签位置、正式关联、规则启用、执行账号、执行日志、后继规则和异步窗口逐项诊断。不要直接替我改状态。
```
### 2.3 请求修改规则
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
只允许修改项目【项目名】中的规则【精确规则名/控制ID】，目标是【目标】。
修改前备份触发、条件、动作、顺序、启用状态和执行账号；一次只改一条，保存后重新打开核对，并用隔离需求做正向和负向测试。禁止修改生产流水线及无关规则。
```
## 3. 项目管理员与流程负责人
### ADM01 项目首次审计或接管
触发：新项目接入、规则无人维护或准备复制到另一个项目。
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
请审计项目【项目名】，先判断是stage_tasks、oneos_delivery还是迁移中。盘点工作流状态、标签、工作项类型、全部自动化规则、执行账号、前后端仓库、dev/develop、Testhub、缺陷状态、test/prod流水线、发布证据和验收门禁。
输出当前—目标差距、规则控制ID映射、风险、P0-P3实施顺序和不能自动化的人工门禁。不要修改线上配置。
```
完成证据：项目画像、规则清单、模型判断、缺口和迁移阶段齐全。
### ADM02 迁移到OneOS终态模型
触发：准备从阶段任务切换到交付主任务模型。
```text
使用 yunxiao-requirement-lifecycle，权限=plan。
项目【项目名】准备迁移到oneos_delivery。请检查待测试、发布中、发布失败状态，交付主任务识别方式，开发/测试/发版任务工作流，A03/A06/A08/A09幂等与负责人，多仓库MR门禁、Testhub分包、生产证据和L01/L02状态。
只有十项迁移门禁全部通过才给出停用旧R/TK规则清单；否则保留现网主链，只列安全可做项和回滚方案。
```
完成证据：迁移门禁逐项结论，而不是笼统“可以迁移”。
### ADM03 规则变更后回归
触发：新建、修改、启停任何生命周期规则。
```text
使用 yunxiao-requirement-lifecycle，权限=test。
项目【项目名】刚修改规则【规则名/控制ID】。请创建或复用隔离测试需求，验证事件【事件】、源状态【状态】、目标状态【状态】，并增加错误状态、无正式关联、部分MR、重复回调或后继连锁等负向场景。
结果只能记录为通过、异步通过、未触发、误触发或阻塞，并附执行日志和回滚入口。
```
### ADM04 定期治理
触发：季度检查、状态/标签重命名、新增仓库或人员离职。
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
请对项目【项目名】执行运行治理检查：规则执行账号和权限、失败日志、状态/标签重命名影响、新增仓库Webhook、多仓库MR覆盖、超过7天无活动分支、回调签名/幂等/重试、L01/L02以及生产和验收证据分离。
输出需要立即修复、计划修复和仅观察三类清单。
```
## 4. 产品负责人
### PO01 新建并确认需求
触发：需求范围、负责人、优先级和验收标准已明确。
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需要建立需求【标题】。范围：【范围】；不包含：【排除项】；负责人：【姓名】；优先级：【级别】；目标迭代：【迭代】；验收标准：【标准】。
请先查重，再创建或完善产品类需求。若项目为oneos_delivery，校验唯一【交付】主任务；若仍为stage_tasks，不要擅自创建主任务。完成后告诉我需求编号、正式关系、当前状态和下一责任人。
```
### PO02 批准进入分析或快轨待开发
触发：需求确认后决定正常分析，或低风险小改走快轨。
正常路径：
```text
项目【项目名】需求【编号】已确认，批准进入分析。使用 yunxiao-requirement-lifecycle，权限=apply。请核查范围、负责人和验收标准齐全，再按当前流程模型触发分析入口；不要跳过缺失信息。
```
快轨路径：
```text
项目【项目名】需求【编号】批准快轨到待开发，批准人【姓名】，原因【原因】，验收标准【标准】。使用 yunxiao-requirement-lifecycle，权限=apply。请确认快轨边存在、唯一交付主任务已同步且没有循环风险；缺少任一条件就停止并报告。
```
### PO03 需求范围变更
触发：开发或测试中修改范围。
```text
使用 yunxiao-requirement-lifecycle，权限=plan。
项目【项目名】需求【编号】当前【状态】，拟变更：【新增/删除内容】；原因：【原因】；受影响资产：【开发任务/MR/用例/缺陷/发布范围】。
请先做影响分析，列出需要重开或新增的任务、MR、用例和验收项，以及是否应回退需求状态。未经我确认不要直接改状态或删除已有证据。
```
### PO04 产品验收通过并关闭
触发：生产发布完成，业务验收通过。
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】当前为发布完成。验收人【姓名】，验收时间【时间】，验收环境【生产】，验收结果【通过】，证据【链接/附件/记录】。
请核查生产发布证据与需求范围一致，并确认不存在未关闭验收项；满足后执行已关闭并回报审计证据。不得用流水线成功替代本次验收。
```
### PO05 验收不通过
```text
使用 yunxiao-requirement-lifecycle，权限=plan。
项目【项目名】需求【编号】生产验收不通过。问题：【问题】；证据：【证据】；影响：【影响】。
请创建或关联可追踪缺陷/改进任务，建议应回到的真实状态和责任人；未经批准不要直接关闭需求或覆盖原发布记录。
```
## 5. 需求分析人员
### BA01 开始分析
```text
项目【项目名】需求【编号】由我开始分析，实际开始时间【时间】。使用 yunxiao-requirement-lifecycle，权限=apply。请核查当前状态和我的关联任务，将分析任务改为处理中并确认需求进入分析中；如果项目为oneos_delivery，则按主任务权威方向同步，避免双向循环。
```
### BA02 分析完成
```text
项目【项目名】需求【编号】分析已完成。产物：【需求说明/流程/字段/边界链接】；未决项：【无或列表】；验收口径：【口径】。
使用 yunxiao-requirement-lifecycle，权限=apply。请先检查分析任务非零且全部完成、产物可访问、未决项已处理，再推进分析完成；回报触发的是原生规则、桥接还是人工门禁。
```
## 6. 设计人员
### UX01 开始设计
```text
项目【项目名】需求【编号】开始设计，设计负责人【姓名】，原型地址【地址】，实际开始时间【时间】。使用 yunxiao-requirement-lifecycle，权限=apply。请核查正式关联设计任务和当前状态，再更新设计任务为处理中并确认需求进入设计中。
```
### UX02 设计完成并交接开发
```text
项目【项目名】需求【编号】设计完成。原型版本【版本】；设计稿【链接】；交互说明【链接】；响应式范围【范围】；已确认人【姓名】；遗留项【无或列表】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查设计任务和交付物后完成设计阶段，并检查是否只创建一组正确的开发任务。不要因为标题含“开发”就视为已正式关联。
```
完成证据：设计任务已完成、需求到设计完成；后继开发任务创建成功后才到待开发。
## 7. 交付负责人
### DL01 创建或核查唯一交付主任务
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】需要建立【交付】主任务，负责人【姓名】。请先按正式关系和交付标签查重；不存在才创建，存在一条则复用，存在多条则停止并列出冲突。主任务必须正式关联需求，不能只靠标题前缀。
```
### DL02 阶段同步异常
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】需求【编号】状态【需求状态】，交付主任务【任务编号】状态【任务状态】，两者不一致。
请判断权威方向、检查Y01-Y16、来源防重和执行日志，说明应补偿哪个对象。不要同时双向写入造成循环。
```
## 8. 技术负责人
### TL01 拆分开发任务
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】已到待开发。请按以下范围拆分开发任务：前端【范围/负责人/仓库】，后端【范围/负责人/仓库】，其他【范围】。每条任务必须正式关联需求和交付主任务、标签=开发、状态=待处理，并记录目标dev/develop分支。查重后创建，禁止重复任务。
```
### TL02 仅前端或仅后端需求
```text
项目【项目名】需求【编号】只涉及【前端/后端】，不涉及【另一端】。使用 yunxiao-requirement-lifecycle，权限=apply。请只创建实际需要的开发任务，并把不涉及的仓库明确记为不适用；不要用缺少另一端MR阻塞，也不要把未盘点仓库默认为已完成。
```
### TL03 开发完成门禁核查
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】需求【编号】准备判定开发完成。相关仓库：【列表】；开发任务：【列表】；MR：【列表及目标分支】。
请确认所有非取消开发任务完成、所有相关MR正式双关联并合并到真实dev/develop；任一仓库未完成都保持开发中。输出缺口，不要手工改成开发完成。
```
## 9. 开发人员
### DEV01 真实开始开发并创建分支
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
我开始处理项目【项目名】需求【编号】的开发任务【任务编号】，真实开始时间【时间】，仓库【仓库名】，基线【dev/develop】，拟建分支【feature/编号或fix/编号】。
请先确认基线真实存在且任务为待处理，再从基线创建或指导创建分支，并确保分支同时正式关联需求和开发任务。完成后核查需求=开发中、任务=处理中；不要用首次提交时间覆盖真实开始时间。
```
### DEV02 提交代码并创建MR
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】，开发任务【任务编号】，仓库【仓库】，分支【分支】，目标分支【dev/develop】。改动摘要：【摘要】；本地验证：【命令和结果】。
请先拉取并检查冲突，再按仓库规范提交、推送并创建MR；MR必须正式关联需求和开发任务。不要直接推保护分支，不要因为提交成功就把开发标为完成。
```
### DEV03 多仓库部分完成
```text
项目【项目名】需求【编号】目前仅仓库【仓库A】的MR【编号】已合并，仓库【仓库B】仍在开发。使用 yunxiao-requirement-lifecycle，权限=audit。请确认需求和交付主任务仍保持开发中，并检查是否存在“部分MR导致提前完成”的误触发规则。
```
## 10. 代码评审人员
### REV01 评审要求修改
```text
项目【项目名】MR【编号】评审不通过，需要修改：【问题列表】。使用 yunxiao-requirement-lifecycle，权限=document。请把评审结论关联到需求【编号】和开发任务【编号】，确认MR保持未合并、开发任务保持处理中、需求保持开发中。
```
### REV02 MR合并后核查
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】MR【编号】已合并到【dev/develop】，关联需求【编号】、开发任务【编号】。请等待异步窗口后核查任务状态；再汇总同需求所有仓库和MR。只有全部相关任务和MR完成才允许需求进入开发完成，并确认测试任务只创建一条。
```
## 11. 测试负责人和测试人员
### QA01 建立测试任务和用例范围
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】开发已完成，目标迭代【迭代】，测试负责人【姓名】。请查重后创建或复用唯一【测试】任务，并将测试计划按需求编号建立独立用例包。范围：【功能/接口/权限/兼容/回归】；不适用：【列表】。正式关联需求、主任务和测试计划后进入待测试。
```
### QA02 test部署成功，开始测试
```text
项目【项目名】需求【编号】的test部署成功，流水线【名称】，执行ID【ID】，环境【test】，部署时间【时间】。使用 yunxiao-requirement-lifecycle，权限=apply。请校验执行ID、范围和重复回调，再允许测试任务和需求进入测试中。明确记录：本事件不能推进发布完成。
```
### QA03 用例失败并提交缺陷
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】，测试计划【计划】，用例【用例ID】执行失败。环境【环境】；前置条件【条件】；步骤【步骤】；实际结果【实际】；期望结果【期望】；证据【截图/日志】；严重程度【级别】。
请查重后创建或关联缺陷，并把缺陷与原用例、需求正式关联。保持用例未通过、测试任务和需求测试中；不要把创建缺陷当作测试完成。
```
### QA04 缺陷复测通过
```text
项目【项目名】缺陷【编号】已在环境【环境】复测，原用例【用例ID】重新执行通过，证据【证据】，复测人【姓名】，时间【时间】。
使用 yunxiao-requirement-lifecycle，权限=apply。请将原用例更新为通过，并把缺陷进入项目真实关闭态；随后重新核查本需求是否仍有未执行、阻塞、失败用例或未关闭缺陷。
```
### QA05 缺陷复测失败
```text
项目【项目名】缺陷【编号】复测失败，原用例【用例ID】仍未通过。实际结果【结果】；证据【证据】。
使用 yunxiao-requirement-lifecycle，权限=apply。请重开缺陷或转回项目真实处理中状态，保持原用例未通过、需求测试中，并通知原修复负责人。不要保留“已修复/已关闭”。
```
### QA06 测试验收完成
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】需求【编号】申请完成测试。测试计划【计划】；用例包【范围】；执行统计【通过/失败/阻塞/未执行】；缺陷清单【编号+状态】；测试负责人【姓名】。
请按TC01-TC03和DF01-DF03核查。只有全部范围用例已执行并通过、失败用例已复测、缺陷由测试关闭时，才完成测试任务并推进需求测试完成；否则列出阻塞项。
```
## 12. 缺陷修复人员
### BUG01 接收缺陷并开始修复
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
我接收项目【项目名】缺陷【编号】，关联需求【编号】、原用例【ID】，开始修复时间【时间】，仓库【仓库】，拟用分支【fix/缺陷编号】。
请核查缺陷、需求和用例的正式关联，再把缺陷转入真实处理中状态；分支和MR同时关联缺陷、需求及对应开发任务。
```
### BUG02 修复完成交给测试
```text
项目【项目名】缺陷【编号】已修复。分支【分支】；MR【编号】；合并目标【dev/develop】；验证结果【结果】；部署环境【test/尚未部署】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查代码和部署证据后把缺陷改为已修复并交给测试复测。不要关闭缺陷，不要把原失败用例改为通过。
```
## 13. 运维与发布负责人
### OPS01 test部署回报
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
项目【项目名】test流水线【名称】执行【成功/失败】，执行ID【ID】，提交/MR范围【范围】，时间【时间】。
请核查本次执行关联的需求和幂等记录。成功只允许测试开始；失败保持原状态并记录原因。不要触发生产发布完成。
```
### OPS02 创建迭代发版任务
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】迭代【迭代名/ID】准备发版，计划窗口【时间】，负责人【姓名】，本批需求【编号列表】，生产流水线【名称】。
请查重后创建或复用唯一【发版】任务，正式关联迭代和本批需求，并生成发布范围与回滚项。需求未测试完成或范围不一致时停止，不进入发布中。
```
### OPS03 开始生产发布
```text
项目【项目名】发版任务【编号】批准开始生产发布。审批人【姓名】；窗口【时间】；生产流水线【名称】；本批需求【列表】；回滚方案【链接】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查全部需求测试完成、范围一致和审批证据，再进入发布中。只操作明确的生产发布，不修改流水线定义。
```
### OPS04 生产发布成功
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】生产流水线【名称】执行成功，执行ID【ID】，环境【prod】，完成时间【时间】，发布范围【需求/MR/版本】，证据【链接】。
请验证签名、时间戳、执行ID幂等和范围，推进发版任务及本批需求到发布完成并停留，通知产品验收。禁止自动进入已关闭。
```
### OPS05 生产发布失败或重试
失败：
```text
项目【项目名】生产流水线【名称】执行失败，执行ID【ID】，失败阶段【阶段】，原因【原因】，影响需求【列表】，回滚结果【结果】。
使用 yunxiao-requirement-lifecycle，权限=apply。请记录失败证据并推进到发布失败；不得伪造成功或关闭需求。
```
重试：
```text
项目【项目名】发版任务【编号】批准从发布失败重试，批准人【姓名】，新执行ID【ID】，已修正原因【说明】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查发布失败→发布中流转边、幂等键和范围后开始重试，保留原失败记录。
```
## 14. 业务验收人员
### ACC01 验收通过
```text
我是业务验收人【姓名】。项目【项目名】需求【编号】已在生产环境按验收项【列表】验证通过，时间【时间】，证据【链接/附件】。
使用 yunxiao-requirement-lifecycle，权限=apply。请核查身份、发布完成状态和证据范围后关闭需求，并保留验收记录。
```
### ACC02 验收不通过
```text
我是业务验收人【姓名】。项目【项目名】需求【编号】生产验收不通过，失败项【列表】，实际结果【结果】，证据【证据】。
使用 yunxiao-requirement-lifecycle，权限=plan。请建立可追踪问题清单，分析应回到测试、开发还是重新发布，并指定下一责任人；不要关闭需求。
```
## 15. 集成桥接负责人
### INT01 回调未生效或重复
```text
使用 yunxiao-requirement-lifecycle，权限=audit。
桥接控制【A03/A06/A08/A09/其他】，项目【项目名】，需求【编号】，事件ID【ID】，时间戳【时间】，回调结果【未生效/重复/失败】，日志摘要【摘要】。
请核查签名、时间窗、防重放、幂等键、当前状态、权限、重试和审计日志。不要绕过校验直接补写状态；给出安全重试或人工回退方案。
```
### INT02 幂等补偿
```text
使用 yunxiao-requirement-lifecycle，权限=apply。
项目【项目名】控制【控制ID】需要补偿，原事件ID【ID】，期望对象【任务/状态】，当前对象【实际】。已确认原操作未成功且不存在重复对象。
请再次查询幂等键和正式关系，只补偿缺失动作；完成后输出新旧事件关联、对象ID和重复检查证据。
```
## 16. 异常和催办话术
### 状态长时间不动
```text
项目【项目名】需求/任务【编号】在【状态】停留【时长】，最后真实事件【事件】，负责人【姓名】，关联资产【列表】。使用 yunxiao-requirement-lifecycle，权限=audit。请判断是业务未完成、自动化未触发还是异步失败，并给出下一责任人和最小恢复动作；不要直接跳状态。
```
### 状态被提前推进
```text
项目【项目名】需求【编号】从【源状态】意外进入【目标状态】，时间【时间】。使用 yunxiao-requirement-lifecycle，权限=audit。请检查后继规则、全部关联项口径、部分MR、未复测缺陷、test/prod混用和L01/L02，定位真实触发规则并给出回滚建议。未经确认不要回退状态。
```
### 任务重复创建
```text
项目【项目名】需求【编号】出现重复【交付/开发/测试】任务：【任务列表】。使用 yunxiao-requirement-lifecycle，权限=audit。请检查幂等键、正式关系和重复回调，确定保留项及合并/取消方案。未经授权不要删除任务。
```
## 17. 节点交接清单
每次角色交接都让Codex确认以下内容：
1. 项目、需求、任务和流程模型准确。
2. 源状态与目标状态明确。
3. 事件真实发生，且正式关联可见。
4. 当前责任人和下一责任人明确。
5. 交付物、代码、用例、缺陷或发布证据可访问。
6. 正向条件全部满足，负向阻塞项为零。
7. 自动化结果与人工准备动作分开记录。
8. 异步等待后重新核查状态和执行日志。
9. 没有误触发后继规则或重复创建。
10. 回滚入口、人工回退和未完成事项已记录。
Codex的节点回报统一使用：
```text
项目：
流程模型：
工作项：
源状态 → 实际状态：
本次真实事件：
执行动作：
触发方式：原生规则/桥接/人工门禁/未触发
验证结果：通过/异步通过/未触发/误触发/阻塞
证据：
未完成项：
下一责任角色：
允许的下一动作：
回滚入口：
```

417
.cursor/skills/yunxiao-requirement-lifecycle/references/simple-role-commands.md Normal file
View File

@@ -0,0 +1,417 @@
# 云效日常口语化操作口令
## 1. 先说一次项目
每次新会话先输入：
```text
项目：统一运营管理平台PC端
```
之后直接说口令即可。项目没有明确、同一编号可能属于多个项目或用户切换项目时，Codex必须先问清项目，不能猜。
口令可以自然表达，不要求标点完全一致。例如：
- `记录需求：增加车辆批量导出`
- `帮我记录一个需求，增加车辆批量导出`
两句话含义相同。
## 2. 产品和需求
### 记录需求
产品输入：
```text
记录需求：增加车辆批量导出
```
Codex执行：查重后在当前项目创建产品类需求，初始状态为`待处理`，返回需求编号。只有标题也可以先记录；云效必填字段缺失时只追问缺少的字段。
**带模块/原型的记录（OneOS）：** 若口令含模块名或原型（如「记录需求：保险采购」），创建前**先调用 `$oneos-autoprd`**，把「需求说明」写入描述；若用户同时定稿，一并写入「更新内容」。
**统一运营管理平台 · 快路径（强制）：** 项目为「统一运营管理平台 / PC 端」时，先读 [oneos-pc-fast-path.md](oneos-pc-fast-path.md) 与 [oneos-pc-runtime-ids.json](../assets/oneos-pc-runtime-ids.json)。用已验证 `POST /workitem/workitem` 建单（创建时带 `document`），不要探测 `/workitem/create`。推进至「开发中」时状态连跳：`待处理 → 设计完成 → 待开发 → 开发中`。
**优先级 / 推进至 Plan 单选门禁（强制）：** 用户要求 Plan 模式单选，或口令含「优先级」「推进至」需点选时：
1. 先用 `AskQuestion`（可用时）或 Plan 确认拿到 A（紧急/高/中/低）与 B（分析中/设计中/设计完成/开发中）。
2. **禁止**未选时默认「中 + 分析中」并继续建单。
3. 「批准 / Implement 计划」本身不等于已选 A+B；计划里仍是空选项时必须先问清。
4. 标签须用户从云效标签 catalog（`oneos-pc-tag-catalog.md`）点选；禁止按业务条线说明/`lines.ts` 自动推断。点选后 API 打标，失败则停并请用户回复标签名，禁止假装成功。
**完整可复制提示词（推荐）：** 统一运营管理平台建单优先用 [oneos-pc-record-requirement-prompt.md](oneos-pc-record-requirement-prompt.md)——含 `$yunxiao-requirement-lifecycle` + `$oneos-autoprd`、A/B/C 三门禁与 30 项标签枚举。复制该文件「用户口令」整段发给 Agent；确认后再执行快路径。
简短版（填需求名与模块后复制）：
```text
使用 $yunxiao-requirement-lifecycle + $oneos-autoprd
记录需求到云效 · 统一运营管理平台
【需求名】（填写）
【描述来源】$oneos-autoprd，原型/模块：（填写）
请先 Plan 让我点选 A 优先级、B 推进至、C 标签（30 项 catalog，见 oneos-pc-record-requirement-prompt.md；禁止 lines.ts 推断）。
我确认后再执行快路径建单。
```
确认回复示例：`优先级：高；推进至：设计完成；标签：运维管理条线`
### 确认需求
产品输入：
```text
确认需求：ONEOSP-123
```
Codex执行：检查范围、负责人、优先级和验收标准，齐全后把需求改为`已确认`。
`确认需求`默认不创建分析任务。确认和真实开始分析是两个事件，防止开始时间失真。由分析人员下一步输入`开始分析`。
### 需求定稿（原型 + AutoPRD）
产品输入：
```text
保险采购需求定稿
```
或：
```text
需求定稿：ONEOSP-123；模块=保险采购
```
Codex执行：
1. 调用 `$oneos-autoprd` 定稿流程：更新原型 `.spec/requirements-prd.md` 第 10 章「功能变更记录」与 `autoprd-baseline.json`（只记功能/逻辑，不记样式/UI/表结构）。
2. 若已有云效需求编号：刷新描述中的「需求说明」与「更新内容」；旧更新内容 →「更新内容·历史」。
3. 若口令要求进待开发/发对象存储：继续走下方「快速进入开发」或 OneOS 快轨口令，不得跳过 AutoPRD。
### 快速进入开发
产品输入：
```text
快速开发：ONEOSP-123；原因=小改动；负责人=张三；范围=只改后端
```
Codex执行：检查项目是否允许快轨、验收标准是否明确，再跳过不需要的分析/设计阶段并建立必要开发任务。条件不齐时不跳状态，只提示缺少什么。
**OneOS 模块已定型进待开发（推荐）：**
```text
「保险采购」需求已经确定：先 AutoPRD 写需求说明与更新内容；发布对象存储并写入描述；
推进到待开发；自动建与需求同名的【交付】任务并正式关联；负责人何斐。
```
执行前必须先跑 `$oneos-autoprd`（含定稿变更记录若用户刚定稿）。进入待开发时**必须**执行 [auto-stage-task.md](auto-stage-task.md)（同名任务、标签交付、负责人何斐、时间沿用需求）；已有唯一交付任务则复用并改负责人为何斐，禁止建第二条。
### 需求变更
产品输入：
```text
变更需求：ONEOSP-123；增加导出时间筛选
```
Codex执行：先分析受影响的任务、MR、用例、缺陷和发布范围，给出应回到哪个阶段；产品确认后再修改，不直接覆盖历史说明。涉及原型功能变更时，同步 `$oneos-autoprd` 更新 PRD；用户再说「定稿」时写入第 10 章。
## 3. 分析和设计
### 开始分析
分析人员输入：
```text
开始分析：ONEOSP-123；负责人=李四
```
Codex执行：
1. 将需求推进到`分析中`（或确认已在分析中）。
2. **按 [auto-stage-task.md](auto-stage-task.md)**：查重后创建/复用与需求**同名**任务；标签=`分析`；正式关联需求；负责人默认=需求**创建人**（口令写了负责人则用口令）；计划开始/创建时间沿用需求。
3. 任务进入`处理中`（或项目约定的开工态）。
4. `stage_tasks`：需求标签含`分析`。`oneos_delivery`：不因此再建第二条【交付】主任务。
### 分析完成
分析人员输入：
```text
分析完成：ONEOSP-123；说明=https://...
```
Codex执行：检查分析产物和未决项；完成对应任务或主任务阶段，核查需求进入`分析完成`。
### 开始设计
设计人员输入：
```text
开始设计：ONEOSP-123；负责人=王五
```
Codex执行：
1. 将需求推进到`设计中`。
2. **按 auto-stage-task**：同名任务；标签=`设计`；正式关联；负责人默认=需求**创建人**（口令可覆盖）；时间沿用需求。
3. 任务开工态同上。
4. `oneos_delivery`：不同时新建交付主任务（交付主任务在待开发时建/复用）。
### 设计完成
设计人员输入：
```text
设计完成：ONEOSP-123；原型=https://...
```
Codex执行：检查原型或设计说明，完成设计任务/主任务阶段，核查需求进入`设计完成`。
如果项目已经部署并验证自动建开发任务的桥接，而且负责人、仓库和范围明确，Codex继续查重并创建开发任务；否则停在`设计完成`，提示技术负责人输入`安排开发`。不得创建无负责人或重复任务。
**进入待开发时（含快轨）：** 必须再跑 auto-stage-task：同名任务、标签`交付`（或`开发`）、负责人**何斐**、正式关联、时间沿用需求。
## 4. 开发
### 安排开发
技术负责人输入：
```text
安排开发：ONEOSP-123；前端=张三/ln-one-os-web；后端=李四/ln-cloud
```
只改一端时可以说：
```text
安排开发：ONEOSP-123；只改后端=李四/ln-cloud
```
Codex执行：按实际范围创建一条或多条`【开发】`任务，正式关联需求；`oneos_delivery`还要关联交付主任务。任务初始为`待处理`，需求进入`待开发`。明确“不涉及”的仓库不会成为完成门禁。
### 开始开发
开发人员输入：
```text
开始开发：ONEOSP-123；任务=TASK-456；仓库=ln-cloud
```
Codex执行：记录真实开始时间，确认真实基线`dev`或`develop`，创建`feature/ONEOSP-123`并同时正式关联需求和开发任务。任务进入`处理中`，需求进入`开发中`。
首次提交只作兜底，不覆盖这次真实开始时间。
### 提交代码
开发人员输入：
```text
提交代码：ONEOSP-123；任务=TASK-456；仓库=ln-cloud
```
Codex执行：检查改动和测试，先拉取并处理冲突，再提交、推送并创建合并到真实`dev/develop`的MR；MR同时关联需求和开发任务。提交成功不等于开发完成。
### 开发完成
开发人员或技术负责人输入：
```text
开发完成：ONEOSP-123
```
Codex执行：汇总该需求所有非取消开发任务、前后端仓库和正式关联MR。只有全部任务完成、全部相关MR已合并，才确认需求进入`开发完成`；少一个仓库也不提前完成。
条件满足后，如果项目已配置并验证唯一测试任务桥接，则查重创建测试任务；否则提示测试负责人输入`提交测试`。
## 5. 测试和缺陷
### 提交测试
测试负责人或开发负责人输入：
```text
提交测试：ONEOSP-123；test流水线=oneos-web-test
```
Codex执行：确认开发完成，触发或核查明确的test流水线。部署成功后，查重创建并正式关联唯一测试任务和需求用例包，进入`待测试/测试中`的项目真实状态。
test成功只允许开始测试，不能变成发布完成。
### 开始测试
测试人员输入：
```text
开始测试：ONEOSP-123；负责人=赵六
```
Codex执行：核查test部署和测试任务，把测试任务改为`测试中/处理中`，需求进入`测试中`。
### 发现Bug
测试人员输入：
```text
发现Bug：ONEOSP-123；用例=CASE-12；现象=车辆来源显示0；期望=显示中文来源
```
Codex执行：查重后创建缺陷，正式关联需求、原失败用例和必要开发任务；用例保持未通过，需求保持`测试中`。
### Bug修复完成
开发人员输入：
```text
Bug修复完成：BUG-123；MR=456；已部署test
```
Codex执行：核查代码、MR和test部署后，把缺陷改为`已修复`并交给测试复测。不会关闭缺陷，也不会把原用例直接改成通过。
### 复测通过
测试人员输入：
```text
复测通过：BUG-123；用例=CASE-12
```
Codex执行：重新记录原用例为通过，把缺陷改为项目真实关闭态，再检查该需求是否还有失败、阻塞、未执行用例或未关闭缺陷。
### 复测失败
测试人员输入：
```text
复测失败：BUG-123；用例=CASE-12；现象=仍显示0
```
Codex执行：原用例保持未通过，缺陷重开或回到处理中，并通知修复负责人；需求保持`测试中`。
### 测试完成
测试负责人输入：
```text
测试完成：ONEOSP-123
```
Codex执行：检查本需求用例包，不按整个迭代一刀切。只有没有未执行、阻塞、失败用例，且所有缺陷都经过测试复测关闭，才完成测试任务并推进需求到`测试完成`。
## 6. 发布和验收
### 准备发布
运维或项目负责人输入：
```text
准备发布：迭代V1.3；需求=ONEOSP-123,ONEOSP-124；窗口=今晚22:00
```
Codex执行：检查本批需求均测试完成，查重创建或复用唯一`【发版】`任务，正式关联迭代和需求，生成发布范围及回滚清单。
### 开始发布
运维输入：
```text
开始发布：发版任务=TASK-900；prod流水线=oneos-prod；审批人=王经理
```
Codex执行：核查审批、本批范围、生产流水线和回滚方案后进入`发布中`。这句话授权执行明确的本次生产发布，但不授权修改生产流水线定义。
### 发布成功
运维输入：
```text
发布成功：执行ID=PIPE-789；发版任务=TASK-900
```
Codex执行：到生产流水线核查环境、执行ID、范围和成功证据，确认后推进本批需求到`发布完成`并停留，等待验收。只说“成功”但没有生产证据时不改状态。
### 发布失败
运维输入：
```text
发布失败：执行ID=PIPE-789；原因=镜像拉取失败
```
Codex执行：核查失败证据，记录原因并进入项目真实`发布失败`状态；项目尚无该状态时记录阻塞并给出人工处置，不创建近义重复状态。
### 验收通过
产品或业务输入：
```text
验收通过：ONEOSP-123；验收人=王经理；证据=https://...
```
Codex执行：核查生产发布完成和验收证据后，把需求改为`已关闭`。发布成功不能代替本句验收。
### 验收不通过
产品或业务输入：
```text
验收不通过：ONEOSP-123；问题=导出字段缺失
```
Codex执行：创建或关联可追踪问题，判断应回到开发、测试还是重新发布，先给出处理建议；不关闭需求，不覆盖原发布记录。
## 7. 随时可用的查询口令
```text
查状态：ONEOSP-123
下一步：ONEOSP-123
为什么没流转：ONEOSP-123
查重复任务：ONEOSP-123
查关联代码：ONEOSP-123
查测试闭环：ONEOSP-123
给我回滚方案：刚才那条规则
```
这些口令默认只查询或出方案，不修改云效。
## 8. Codex的简短回报格式
处理成功：
```text
已处理：ONEOSP-123
状态：已确认 → 分析中
任务：已创建并关联分析任务 TASK-456
下一步：分析人员输入“分析完成：ONEOSP-123；说明=链接”
```
条件不足：
```text
暂未处理：ONEOSP-123
缺少：开发负责人
请补充：安排开发：ONEOSP-123；只改后端=负责人/仓库
```
自动化未触发：
```text
未触发：ONEOSP-123 仍为待开发
原因：分支只写了需求编号，没有在云效正式关联开发任务
下一步：我可以补正式关联，然后再核查一次
```
## 9. Codex执行口令的规则
1. `记录、确认、开始、完成、提交、修复、复测、准备发布、发布、验收`属于当前项目和明确工作项的执行授权。
2. `查、看看、为什么、下一步、给方案`只允许读取或规划。
3. 写操作前必须确认当前项目；项目不清楚只问项目名。
4. 其他必要字段缺失时只追问最少信息，不发送长表单。
5. 先查重、再创建；任务幂等键使用项目ID、需求ID和阶段类型。
6. 项目使用`stage_tasks`还是`oneos_delivery`由Codex识别，同事不需要记规则编号。
7. 当前平台或桥接不支持的动作要明确说“需要人工一步”，不能伪装成已自动化。
8. 自动规则执行后等待5–30秒，再回看状态、正式关联和执行日志。
9. 不用手工改最终状态冒充自动化通过。
10. 不修改生产流水线定义，不删除规则、分支、MR、任务或测试资产，除非用户单独明确授权。

87
.cursor/skills/yunxiao-requirement-lifecycle/references/task-lifecycle.md Normal file
View File

@@ -0,0 +1,87 @@
# 阶段任务生命周期与自动创建
## 目录
1. 目标链路
2. TK01–TK08规则
3. 关系与代码资产
4. 原生规则和桥接边界
5. 验证与回滚
## 1. 目标链路
```text
需求设计中 + 设计任务处理中
→ 设计任务已完成
→ 需求设计完成
→ 创建并关联开发任务
→ 需求待开发 + 开发任务待处理
→ 正式关联需求分支
→ 需求开发中 + 开发任务处理中
→ 全部相关MR合并到真实dev/develop
→ 需求开发完成 + 开发任务已完成
→ test流水线部署成功
→ 创建并关联测试任务
→ 需求测试中 + 测试任务处理中
→ 用例全部通过且缺陷复测关闭
→ 需求测试完成 + 测试任务已完成
```
分支只能合并到集成分支，不能“合并到测试环境”。test环境由流水线部署；部署成功用于允许测试开始，不用于证明生产发布。
## 2. TK01–TK08规则
| ID | 触发 | 必要条件 | 动作 | 推荐实现 |
|---|---|---|---|---|
| TK01 | 需求进入设计中 | 已正式关联设计任务；任务标签=`设计` | 设计任务保持待处理，负责人真实开工后人工改为处理中 | 默认+人工 |
| TK02 | 设计任务变为已完成 | 需求当前状态=设计中；本阶段设计任务非零且全部完成 | 需求改为设计完成 | 原生规则 |
| TK03 | 需求变为设计完成 | 不存在同需求、同阶段、未取消的开发任务 | 创建并正式关联开发任务，标签=`开发`，状态=待处理 | API/Webhook桥接 |
| TK04 | 开发任务创建并关联成功 | 需求当前状态=设计完成；开发任务关系可见 | 需求改为待开发 | 原生规则 |
| TK05 | 正式关联需求分支/代码资产 | 需求=待开发；开发任务=待处理；资产同时关联需求和开发任务 | 需求改为开发中；开发任务改为处理中 | 原生规则 |
| TK06 | 关联合并请求状态变化 | 需求=开发中；开发任务=处理中；全部相关前后端MR已合并到真实集成分支 | 需求改为开发完成；开发任务改为已完成 | 原生规则 |
| TK07 | test流水线部署成功 | 需求=开发完成；执行ID未处理；不存在同需求、同阶段、未取消的测试任务 | 创建并关联测试任务，关联测试计划/用例，任务改为处理中，需求改为测试中 | API/Webhook桥接 |
| TK08 | 测试验收完成 | 用例全部通过；失败用例已复测；范围内缺陷均由测试关闭 | 测试任务改为已完成；需求改为测试完成 | 桥接/人工门禁 |
## 3. 关系与代码资产
- 设计、开发、测试任务必须使用云效正式父子项或关联项关系，不依赖标题关键字。
- 开发分支和MR必须同时关联产品需求与对应开发任务；只关联需求不能可靠更新开发任务。
- 一个需求涉及多个仓库时，全部相关前端、后端MR都纳入TK06门禁。
- 首次提交可能晚于真实开工。任务`处理中`的权威时间是负责人执行“开始处理”；分支关联仅作自动兜底。
## 4. 原生规则和桥接边界
优先使用云效原生规则处理状态变化、父子项、关联项和Codeup对象。若当前规则编辑器没有“创建工作项”动作，TK03和TK07必须标记为`integration_bridge`或`not_supported`，不得声称已经自动创建。
桥接创建任务时使用幂等键：
```text
项目ID + 需求ID + 阶段类型
```
重复回调先查询是否存在未取消的同阶段任务；存在则复用并校验正式关系，不重复创建。流水线回调还要校验签名、时间戳、执行ID、防重放和失败重试。
## 5. 验证与回滚
- 正向验证每个TK控制，并检查需求和任务两个对象的状态。
- 负向验证零任务、错误标签、错误当前状态、未正式关联分支、只合并部分MR、流水线失败和重复回调。
- 新规则不会补触发历史事件。历史任务仅在核对MR/流水线证据后人工修正，并标记为测试准备或数据修复。
- 回滚时先禁用新增规则或桥接入口，不删除已有任务和关系；恢复前一状态需要单独业务确认。
## 6. 进阶段自动建同名任务（与 OneOS / 口令共用）
完整规则见 [auto-stage-task.md](auto-stage-task.md)。摘要：
| 需求状态 | 同名任务标签 | 负责人 |
|---|---|---|
| 分析中 | `分析` | 需求创建人 |
| 设计中 | `设计` | 需求创建人 |
| 待开发 | `交付` 或 `开发` | 何斐 |
必须正式关联需求；计划开始/创建时间沿用需求；同阶段幂等查重。
当创建或修复**分析 / 设计 / 交付(开发)**任务时：
1. **任务标签（右侧基础字段）**：分析 → `分析`；设计 → `设计`；待开发主任务 → `交付`（或 `开发`）。Title 同名或前缀 alone 不够。
2. **正式关联需求**：每条阶段任务必须链接到**产品需求**（父子或关联项）。只关联其他任务不算完成。
3. 创建/修复后先核对标签与可见需求关系，再报告成功。

62
.cursor/skills/yunxiao-requirement-lifecycle/references/test-defect-closure.md Normal file
View File

@@ -0,0 +1,62 @@
# 测试用例与缺陷复测闭环
## 目录
1. 测试完成门槛
2. TC01–TC03用例控制
3. DF01–DF03缺陷控制
4. 实现方式
5. 验证场景
## 1. 测试完成门槛
R10只有同时满足以下条件才能完成：
1. 范围内用例均已执行并有明确结果。
2. 不存在`未执行/待测试`、`阻塞`或`未通过`用例；获批暂缓/不适用项记录批准人与原因。
3. 每个未通过用例均正式创建或关联缺陷。
4. 修复后重新执行原用例并通过。
5. 范围内缺陷均由测试复测并进入项目真实关闭态。
6. 测试计划或测试验收任务由测试负责人确认。
流水线成功只能证明部署/自动检查成功，不能替代用例结果和缺陷复测。
## 2. TC01–TC03用例控制
| ID | 控制 | 完成口径 |
|---|---|---|
| TC01 | 用例执行 | 每条范围内用例有真实执行结果；未执行、待测试、阻塞、未通过均阻塞测试完成 |
| TC02 | 失败用例关联缺陷 | 每条未通过用例正式创建或关联缺陷；仅写编号或链接不算关联 |
| TC03 | 用例复测更新 | 修复后重新执行原用例；通过才改为已通过，失败保持未通过 |
## 3. DF01–DF03缺陷控制
| ID | 控制 | 完成口径 |
|---|---|---|
| DF01 | 已修复交接 | `已修复`只表示开发交给测试复测，不是终态，不解除测试门禁 |
| DF02 | 复测通过 | 缺陷进入项目真实关闭态，原失败用例同时更新为已通过 |
| DF03 | 复测失败 | 缺陷进入项目真实重开/处理中状态，原用例保持未通过 |
不得关闭缺陷却不更新原用例，也不得在缺陷仅为`已修复`时把用例标为通过。
## 4. 实现方式
先检查当前规则编辑器是否真的暴露Testhub执行用例和缺陷聚合条件：
- 支持时：使用原生聚合规则，并保存条件和执行日志证据。
- 不支持时：使用测试验收任务/人工门禁。
- 需要全自动时：单独评审Testhub OpenAPI/Webhook桥接，要求签名、幂等、失败重试和审计记录。
不能把`not_supported`写成“已自动化”；必须指定负责人和回退方案。
## 5. 验证场景
| 场景 | 操作 | 期望 | 负向检查 |
|---|---|---|---|
| 用例未执行 | 保留一条未执行用例 | 保持测试中 | 不得完成测试 |
| 用例失败 | 记录未通过并正式关联缺陷 | 保持测试中 | 仅建缺陷不得完成 |
| 缺陷已修复 | 开发改为已修复 | 等待测试复测 | 不得关闭或通过用例 |
| 复测通过 | 重跑原用例并通过 | 用例通过、缺陷关闭 | 两者状态必须一致 |
| 复测失败 | 重跑仍失败 | 用例未通过、缺陷重开 | 不得保持已修复/关闭 |
| 全部闭环 | 全部用例通过且缺陷关闭 | 允许R10推进 | 检查是否误触发后继规则 |