OneOS1.2/.cursor/skills/yunxiao-requirement-lifecycle/references/simple-role-commands.md

云效日常口语化操作口令

1. 先说一次项目

每次新会话先输入：

项目：统一运营管理平台PC端

之后直接说口令即可。项目没有明确、同一编号可能属于多个项目或用户切换项目时，Codex必须先问清项目，不能猜。

口令可以自然表达，不要求标点完全一致。例如：

• 记录需求：增加车辆批量导出
• 帮我记录一个需求，增加车辆批量导出

两句话含义相同。

2. 产品和需求

记录需求

产品输入：

记录需求：增加车辆批量导出

Codex执行：查重后在当前项目创建产品类需求，初始状态为待处理，返回需求编号。只有标题也可以先记录；云效必填字段缺失时只追问缺少的字段。

带模块/原型的记录（OneOS）： 若口令含模块名或原型（如「记录需求：保险采购」），创建前先调用 $oneos-autoprd，把「需求说明」写入描述；若用户同时定稿，一并写入「更新内容」。

统一运营管理平台 · 快路径（强制）： 项目为「统一运营管理平台 / PC 端」时，先读 oneos-pc-fast-path.md 与 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——含 $yunxiao-requirement-lifecycle + $oneos-autoprd、A/B/C 三门禁与 30 项标签枚举。复制该文件「用户口令」整段发给 Agent；确认后再执行快路径。

简短版（填需求名与模块后复制）：

使用 $yunxiao-requirement-lifecycle + $oneos-autoprd
记录需求到云效 · 统一运营管理平台

【需求名】（填写）
【描述来源】$oneos-autoprd，原型/模块：（填写）

请先 Plan 让我点选 A 优先级、B 推进至、C 标签（30 项 catalog，见 oneos-pc-record-requirement-prompt.md；禁止 lines.ts 推断）。
我确认后再执行快路径建单。

确认回复示例：优先级：高；推进至：设计完成；标签：运维管理条线

确认需求

产品输入：

确认需求：ONEOSP-123

Codex执行：检查范围、负责人、优先级和验收标准，齐全后把需求改为已确认。

确认需求默认不创建分析任务。确认和真实开始分析是两个事件，防止开始时间失真。由分析人员下一步输入开始分析。

需求定稿（原型 + AutoPRD）

产品输入：

保险采购需求定稿

或：

需求定稿：ONEOSP-123；模块=保险采购

Codex执行：

1. 调用 $oneos-autoprd 定稿流程：更新原型 .spec/requirements-prd.md 第 10 章「功能变更记录」与 autoprd-baseline.json（只记功能/逻辑，不记样式/UI/表结构）。
2. 若已有云效需求编号：刷新描述中的「需求说明」与「更新内容」；旧更新内容 →「更新内容·历史」。
3. 若口令要求进待开发/发对象存储：继续走下方「快速进入开发」或 OneOS 快轨口令，不得跳过 AutoPRD。

快速进入开发

产品输入：

快速开发：ONEOSP-123；原因=小改动；负责人=张三；范围=只改后端

Codex执行：检查项目是否允许快轨、验收标准是否明确，再跳过不需要的分析/设计阶段并建立必要开发任务。条件不齐时不跳状态，只提示缺少什么。

OneOS 模块已定型进待开发（推荐）：

「保险采购」需求已经确定：先 AutoPRD 写需求说明与更新内容；发布对象存储并写入描述；
推进到待开发；自动建与需求同名的【交付】任务并正式关联；负责人何斐。

执行前必须先跑 $oneos-autoprd（含定稿变更记录若用户刚定稿）。进入待开发时必须执行 auto-stage-task.md（同名任务、标签交付、负责人何斐、时间沿用需求）；已有唯一交付任务则复用并改负责人为何斐，禁止建第二条。

需求变更

产品输入：

变更需求：ONEOSP-123；增加导出时间筛选

Codex执行：先分析受影响的任务、MR、用例、缺陷和发布范围，给出应回到哪个阶段；产品确认后再修改，不直接覆盖历史说明。涉及原型功能变更时，同步 $oneos-autoprd 更新 PRD；用户再说「定稿」时写入第 10 章。

3. 分析和设计

开始分析

分析人员输入：

开始分析：ONEOSP-123；负责人=李四

Codex执行：

1. 将需求推进到分析中（或确认已在分析中）。
2. 按 auto-stage-task.md：查重后创建/复用与需求同名任务；标签=分析；正式关联需求；负责人默认=需求创建人（口令写了负责人则用口令）；计划开始/创建时间沿用需求。
3. 任务进入处理中（或项目约定的开工态）。
4. stage_tasks：需求标签含分析。oneos_delivery：不因此再建第二条【交付】主任务。

分析完成

分析人员输入：

分析完成：ONEOSP-123；说明=https://...

Codex执行：检查分析产物和未决项；完成对应任务或主任务阶段，核查需求进入分析完成。

开始设计

设计人员输入：

开始设计：ONEOSP-123；负责人=王五

Codex执行：

1. 将需求推进到设计中。
2. 按 auto-stage-task：同名任务；标签=设计；正式关联；负责人默认=需求创建人（口令可覆盖）；时间沿用需求。
3. 任务开工态同上。
4. oneos_delivery：不同时新建交付主任务（交付主任务在待开发时建/复用）。

设计完成

设计人员输入：

设计完成：ONEOSP-123；原型=https://...

Codex执行：检查原型或设计说明，完成设计任务/主任务阶段，核查需求进入设计完成。

如果项目已经部署并验证自动建开发任务的桥接，而且负责人、仓库和范围明确，Codex继续查重并创建开发任务；否则停在设计完成，提示技术负责人输入安排开发。不得创建无负责人或重复任务。

进入待开发时（含快轨）： 必须再跑 auto-stage-task：同名任务、标签交付（或开发）、负责人何斐、正式关联、时间沿用需求。

4. 开发

安排开发

技术负责人输入：

安排开发：ONEOSP-123；前端=张三/ln-one-os-web；后端=李四/ln-cloud

只改一端时可以说：

安排开发：ONEOSP-123；只改后端=李四/ln-cloud

Codex执行：按实际范围创建一条或多条【开发】任务，正式关联需求；oneos_delivery还要关联交付主任务。任务初始为待处理，需求进入待开发。明确“不涉及”的仓库不会成为完成门禁。

开始开发

开发人员输入：

开始开发：ONEOSP-123；任务=TASK-456；仓库=ln-cloud

Codex执行：记录真实开始时间，确认真实基线dev或develop，创建feature/ONEOSP-123并同时正式关联需求和开发任务。任务进入处理中，需求进入开发中。

首次提交只作兜底，不覆盖这次真实开始时间。

提交代码

开发人员输入：

提交代码：ONEOSP-123；任务=TASK-456；仓库=ln-cloud

Codex执行：检查改动和测试，先拉取并处理冲突，再提交、推送并创建合并到真实dev/develop的MR；MR同时关联需求和开发任务。提交成功不等于开发完成。

开发完成

开发人员或技术负责人输入：

开发完成：ONEOSP-123

Codex执行：汇总该需求所有非取消开发任务、前后端仓库和正式关联MR。只有全部任务完成、全部相关MR已合并，才确认需求进入开发完成；少一个仓库也不提前完成。

条件满足后，如果项目已配置并验证唯一测试任务桥接，则查重创建测试任务；否则提示测试负责人输入提交测试。

5. 测试和缺陷

提交测试

测试负责人或开发负责人输入：

提交测试：ONEOSP-123；test流水线=oneos-web-test

Codex执行：确认开发完成，触发或核查明确的test流水线。部署成功后，查重创建并正式关联唯一测试任务和需求用例包，进入待测试/测试中的项目真实状态。

test成功只允许开始测试，不能变成发布完成。

开始测试

测试人员输入：

开始测试：ONEOSP-123；负责人=赵六

Codex执行：核查test部署和测试任务，把测试任务改为测试中/处理中，需求进入测试中。

发现Bug

测试人员输入：

发现Bug：ONEOSP-123；用例=CASE-12；现象=车辆来源显示0；期望=显示中文来源

Codex执行：查重后创建缺陷，正式关联需求、原失败用例和必要开发任务；用例保持未通过，需求保持测试中。

Bug修复完成

开发人员输入：

Bug修复完成：BUG-123；MR=456；已部署test

Codex执行：核查代码、MR和test部署后，把缺陷改为已修复并交给测试复测。不会关闭缺陷，也不会把原用例直接改成通过。

复测通过

测试人员输入：

复测通过：BUG-123；用例=CASE-12

Codex执行：重新记录原用例为通过，把缺陷改为项目真实关闭态，再检查该需求是否还有失败、阻塞、未执行用例或未关闭缺陷。

复测失败

测试人员输入：

复测失败：BUG-123；用例=CASE-12；现象=仍显示0

Codex执行：原用例保持未通过，缺陷重开或回到处理中，并通知修复负责人；需求保持测试中。

测试完成

测试负责人输入：

测试完成：ONEOSP-123

Codex执行：检查本需求用例包，不按整个迭代一刀切。只有没有未执行、阻塞、失败用例，且所有缺陷都经过测试复测关闭，才完成测试任务并推进需求到测试完成。

6. 发布和验收

准备发布

运维或项目负责人输入：

准备发布：迭代V1.3；需求=ONEOSP-123,ONEOSP-124；窗口=今晚22:00

Codex执行：检查本批需求均测试完成，查重创建或复用唯一【发版】任务，正式关联迭代和需求，生成发布范围及回滚清单。

开始发布

运维输入：

开始发布：发版任务=TASK-900；prod流水线=oneos-prod；审批人=王经理

Codex执行：核查审批、本批范围、生产流水线和回滚方案后进入发布中。这句话授权执行明确的本次生产发布，但不授权修改生产流水线定义。

发布成功

运维输入：

发布成功：执行ID=PIPE-789；发版任务=TASK-900

Codex执行：到生产流水线核查环境、执行ID、范围和成功证据，确认后推进本批需求到发布完成并停留，等待验收。只说“成功”但没有生产证据时不改状态。

发布失败

运维输入：

发布失败：执行ID=PIPE-789；原因=镜像拉取失败

Codex执行：核查失败证据，记录原因并进入项目真实发布失败状态；项目尚无该状态时记录阻塞并给出人工处置，不创建近义重复状态。

验收通过

产品或业务输入：

验收通过：ONEOSP-123；验收人=王经理；证据=https://...

Codex执行：核查生产发布完成和验收证据后，把需求改为已关闭。发布成功不能代替本句验收。

验收不通过

产品或业务输入：

验收不通过：ONEOSP-123；问题=导出字段缺失

Codex执行：创建或关联可追踪问题，判断应回到开发、测试还是重新发布，先给出处理建议；不关闭需求，不覆盖原发布记录。

7. 随时可用的查询口令

查状态：ONEOSP-123
下一步：ONEOSP-123
为什么没流转：ONEOSP-123
查重复任务：ONEOSP-123
查关联代码：ONEOSP-123
查测试闭环：ONEOSP-123
给我回滚方案：刚才那条规则

这些口令默认只查询或出方案，不修改云效。

8. Codex的简短回报格式

处理成功：

已处理：ONEOSP-123
状态：已确认 → 分析中
任务：已创建并关联分析任务 TASK-456
下一步：分析人员输入“分析完成：ONEOSP-123；说明=链接”

条件不足：

暂未处理：ONEOSP-123
缺少：开发负责人
请补充：安排开发：ONEOSP-123；只改后端=负责人/仓库

自动化未触发：

未触发：ONEOSP-123 仍为待开发
原因：分支只写了需求编号，没有在云效正式关联开发任务
下一步：我可以补正式关联，然后再核查一次

9. Codex执行口令的规则

1. 记录、确认、开始、完成、提交、修复、复测、准备发布、发布、验收属于当前项目和明确工作项的执行授权。
2. 查、看看、为什么、下一步、给方案只允许读取或规划。
3. 写操作前必须确认当前项目；项目不清楚只问项目名。
4. 其他必要字段缺失时只追问最少信息，不发送长表单。
5. 先查重、再创建；任务幂等键使用项目ID、需求ID和阶段类型。
6. 项目使用stage_tasks还是oneos_delivery由Codex识别，同事不需要记规则编号。
7. 当前平台或桥接不支持的动作要明确说“需要人工一步”，不能伪装成已自动化。
8. 自动规则执行后等待5–30秒，再回看状态、正式关联和执行日志。
9. 不用手工改最终状态冒充自动化通过。
10. 不修改生产流水线定义，不删除规则、分支、MR、任务或测试资产，除非用户单独明确授权。