yunxiao-development-delivery

云效开发交付

每日首次自动更新（强制，先于其他动作）

每个本地自然日首次触发本 Skill 时，先执行：

node <本 Skill 目录>/scripts/ensure-daily-skill-update.mjs --current-skill yunxiao-development-delivery

• updated：五个云效生命周期 Skill 已统一更新；必须重新完整读取本 SKILL.md 及本次所需引用后再继续，然后再调用 development-brain 做开发预检。
• skipped-today：当天已经成功更新，直接继续。
• in-progress：另一个相关 Skill 正在执行同一更新，直接继续，不并发重复更新。
• failed / unavailable / cooldown：只给一条简短提示，继续当前任务；更新失败不得阻断开发工作。
• 共用更新范围固定为 YunxiaoPM、yunxiao-development-delivery、development-brain、YunxiaoQA、yunxiao-release-operations 的用户级全局安装；不得借此修改项目级 Skill、业务仓、云效数据、流水线或生产环境。不得手工伪造或提前写入每日成功状态。

在不以代码活动替代真实工作状态的前提下，处理开发任务和 Codeup 资产。套件版本：10.2.15。

加载必需的引用文件

• 完成开发 使用不可跳过的产品交接门禁。产品记录缺失、无效、不兼容、不可读或不匹配时，必须停止所有完成流程写入，包括创建或更新测试任务。不得降级为警告、仅更新状态完成、可选工作失败或让用户确认后跳过。保留现有业务记录不变；获取已更正的产品证据并重新执行预检。直接命令、隐式完成、历史恢复和恢复旧预检均使用同一门禁。

• 在正式开始或完成开发前，阅读版本绑定的交接门禁。阅读当前范围内的契约和必需材料，返回已审阅的理解回执及明确的工程决策；绝不推断产品决策。在正式开始／恢复或首次写入业务代码前，立即运行 yunxiao_cli_handoff.py verify --bundle <bundle.json> --task-id <exact internal development ID>：该命令通过官方 CLI 读取实时需求和交付内容，并检查实际材料字节。旧的仅本地 PASS 或较早的预检都不能替代此次实时检查。完成时，将 evidence.handoffEvidence 提供给专用执行器；执行器会检查实时产品清单、内容哈希、任务／版本绑定，并将回执写入开发任务。历史恢复可以收集证据，但不能豁免此正式门禁。此范围内的门禁优先于下文较早的可选哈希／缺失证据兼容说明；无需加载无关的完整 PRD 或此 PM 的本地子代理。

操作前，请完整读取每个选定文件：

• 开发任务、Codeup、stage-task 和 OneOS 控件：references/controls.md。
• 简短中文命令和缺陷修复工作流：references/commands.md。
• 对于隐式调用、自然语言规范化、唯一任务选择，以及开发与测试的区分，请在选择命令前完整阅读 references/semantic-routing.md。
• 开发任务:任务=<ID> 的直接/计划模式、新增/优化材料门禁、原型对比和实现完成：references/implementation-materials.md。
• Codex 任务关联、有效时长统计、分钟到小时的换算，以及完成字段回写：references/codex-time-accounting.md。
• 批量发现、稳定快照、逐任务继续执行、worktree 隔离和最终报告：references/batch-execution.md。
• 本地 Maven/pnpm 依赖发现、分支安全复用和增量安装回退：references/dependency-reuse.md。
• 强制逐节点操作台账、基于 Git 的文件清单、批次归属和阻塞报告：references/change-reporting.md。
• 开始/提交/完成命令拆分、一键 Bug 修复、带保护的分支到工作项匹配，以及发布评论可追溯性：references/branch-submit-release-ledger.md。
• 在首次写入业务代码前，使用 scripts/route_lifecycle_intent.py 和 scripts/resolve_branch_base.py；使用 scripts/yunxiao_cli_delivery_ledger.py 记录仅追加事件，使用 scripts/yunxiao_cli_submission_attempt.py 处理多仓库检查点，并在显式提交成功后使用 scripts/classify_completion_readiness.py，以决定自动完成、进行一次确认或停止。开发台账写入和完成操作使用此 Skill 随附的适配器，并验证实际交接架构和证据；绝不要求安装路径或其他生命周期 Skills 的已安装版本必须匹配。
• Maven API 制品检测、带保护的 SNAPSHOT 部署、干净的使用方重新解析和流水线新鲜度门禁：references/api-artifact-publish.md。
• YunxiaoPM 交接输入、幂等性和下游轮转：references/yunxiaopm-handoff.md。
• 不设测试流水线门禁的测试任务交接，以及发布修复后的重新进入：references/test-deployment-handoff.md。
• 需求级 TestHub 计划发现、交付阶段用例范围、轻量验证和需求完成情况汇总：references/test-scope-aggregation.md。
• 提交后的完成情况评估，以及自动/确认/停止/测试交付决策：references/completion-readiness.md。
• 分支、提交或 MR 早于任务，或缺少任务关联的历史任务：references/historical-code-recovery.md。请根据官方 Codeup 证据还原准确映射；如果已合并 MR 仍能证明交付，不要因当前找不到源分支就认定未交付；也不要按作者或日期采纳同一模块的所有变更。
• 授权、实时变更安全、证据和跨 Skill 交接：references/safety-handoff.md。
• 独立发布任务的分支清理、保留策略、远程删除，以及当前机器上的本地清理：references/release-branch-cleanup.md。
• 对于尚未由专用适配器覆盖的每一项 Yunxiao 平台读写操作，请阅读官方 CLI 网关、事务计划、幂等性和性能规则：references/yunxiao-cli-runtime.md。
• 当用户明确要求快速生命周期，且已证明仓库/部署目标相互隔离时，请阅读并应用 references/rapid-flow.md；切勿将其用于真实生产环境。
• 对于 分配任务，请阅读官方 CLI 环境、哈希预检/应用回执、幂等性、字段、关联和回读规则：references/yunxiao-cli-allocation.md；然后阅读 references/requirement-snapshot.md 和 references/allocation-technical-plan.md。请先创建开发需求快照，再根据该确切快照制定技术计划。
• 对于 修复负责人是我的所有Bug，请阅读官方 CLI 适配器、凭据、冻结快照、状态写入和回退规则：references/yunxiao-cli-bug-batch.md。
• 对于 QA 专用修复通道，请使用 scripts/yunxiao_cli_bug_repair_channel.py 验证并接受 oneos.test-bug-repair-request/v1，然后沿用常规 Bug 修复/合并门禁。
• 通过 references/runtime-launcher.md 中的跨平台启动器约定运行随附的 Python。
• 每次调用时，都必须遵循下方的强制约定调用 $development-brain。该组件拥有独立的知识资源；只传递当前操作、确切 ID、已知范围和非敏感证据指针。不要从此 Skill 读取或复制其安装文件。 此 Skill 中的安全防护是独立完整的。如果也安装了 git-submit-safety，请将其用作额外的仓库专属防护措施。

仅负责开发边界

负责以下结果：

1. 接受已验证且需求已处于 待开发 状态的 YunxiaoPM 移交事项。
2. 分配一个或多个 【开发】子任务，并填写开发人员、计划日期和预估工时。若源 【交付】任务有优先级，则复制并回读该优先级；若没有，则将子任务优先级留空（或仅在平台确定性地应用项目原生默认值时接受该默认值），并记录警告，而不是阻止创建。随后将源 【交付】任务从 待处理 移至 已分配。
3. 在收到明确或语义清晰的开始信号时，首次写入业务代码之前解析正确且已验证的基准。有一个正式事项时，创建或复用其分支；没有正式事项时，创建 tempdev/* 分支实例和本地账本标识。绝不继承无关的当前分支。执行只读的依赖复用检查；若存在正式所属事项，则在变更其状态之前，写入并回读不可变的 【研发启动】事件。启动分支绝不下载、安装、复制或重建依赖。
4. 开始后允许开发人员独立编码。每次提交、推送或创建 MR 之前，都要根据交付账本比对仓库、分支实例、变更摘要和现有 MR。正式且唯一匹配的事项自动提交；TEMPDEV 仅可在明确请求测试部署时推送到其非受保护临时分支，且必须保持 UNADOPTED。正式候选项冲突时，仅暂停该仓库，并展示双方信息以供一次确认。当已验证的变更包含 Maven 公共 API 工件时，仅将已验证的 SNAPSHOT 工件发布到配置的快照仓库，以消费者身份重新解析并确认成功，然后记录回执，之后才可运行依赖它的测试流水线。这属于软件包准备，绝非生产部署或发布到正式仓库。
5. 在 完成开发中，运行验证之前先分类验证方式。通过 yunxiao_testhub_read_api.py 直接读取精确需求对应的 TestHub 计划。默认且固定的请求是官方 ListTestPlan，使用 Content-Type: application/json；绝不先探测已知有问题的 test-hub-list-test-plan CLI，不查询其插件版本，也不把升级或重试该插件作为前置条件。使用环境 PAT，且不跟随重定向。成功读取时记录 available-json-api；实际可重试的服务或传输故障则记录 unavailable-json-api/plan-read-skipped，并附上真实 JSON 错误和追踪 ID，不升级插件。不支持的 Region/自定义端点、身份验证、权限以及格式错误或跨项目响应均会阻塞流程。读取成功但需求没有关联的正式计划时，明确跳过正式计划/用例验证。若精确正式计划配置了当前端范围，则读取真实结果条目，并将去重后的目录和用例 ID 固定到测试移交中；不得更新 TestHub 结果。每个范围仍须执行适用的开发侧完成验证。只有 YunxiaoQA 才能执行已固定的正式用例，并依据真实测试证据写入结果。若某个已推送提交、已合并 MR 或可信集成版本与任务唯一匹配，则复用该版本；不得仅仅因为稍后或在另一台机器上执行完成流程，就创建重复提交或 MR。存在本地变更时，先调用受保护的 提交代码节点。正常模式要求版本已集成或新近合并；明确启用的隔离快速模式可在仅因审查原因拒绝合并后，使用已验证的远程源提交。开发期间自动维护增量 Codex 任务片段索引；完成流程根据开发任务 ID 查询该索引，然后仅执行有界的资产/时间窗口元数据查询和定向深度读取。正常路径绝不全量扫描所有对话，也绝不要求开发人员选择或确认对话。实际工时回写尽力而为：仅当开始时间、时长、操作人员和精度均可审计时才写入并回读；否则记录 工时无可核验来源，不得捏造数值。代码交付和验证证据固定后，所有生命周期写入都必须使用 yunxiao_cli_complete_development.py：先准备测试任务，再关闭开发任务，第三步推进需求，最后执行官方回读。所有完成操作和回读结束后，回顾任务所属变更及有证据支撑的原因。
6. 支持 开始修复bug 和 完成修复bug 两个独立且可追踪的节点。修复bug:<BUG-ID> 执行开始、修复/验证、受保护提交、MR 创建/复用、合并和官方回读。Web 和 小程序 均须通过已验证的开发检查并实际合并 MR，之后才能标记为 已修复。记录 待部署、待交付测试；修复完成时不得发现、启动或等待 Flow。保留 验证人/验证者。
7. 支持 处理测试修复请求：缺陷=<BUG-ID> 作为 QA 到开发的特殊入口。必须读取并验证最新的结构化 QA 请求，追加开发接收评论，然后继续执行现有的 修复bug:<BUG-ID> 操作，不得要求 QA 重述证据。只有在具备合并/验证证据时以 已修复 结束，或在具备原因、审批人、审批证据和后续操作时以 暂不修复 结束；QA 角色绝不写入这两种状态。
8. 每个开发任务取得可信版本后，立即对其需求测试模式进行分类；绝不等待同级开发任务或其工时证据。每个未取消的 【开发】任务都必须在同一交付项下创建或复用且仅创建一个对应的 【测试】子任务，将其关联到同一需求，记录其 developmentTaskId，并指派唯一的 测试主管。若正式 TestHub 计划包含非空的当前端用例，则选择 testMode=formal-plan；若计划读取成功但没有关联计划、没有端标记目录或目录为空，则跳过正式 TestHub 验证并使用 testMode=mandatory-test-task。实际可重试的 JSON 服务/传输故障也使用 mandatory-test-task，记录为 plan-read-skipped，绝不能视为已确认不存在计划。所有这些模式仍要求 QA 完成测试。lightweight-verification 已停用，绝不能用于推进需求或满足发布就绪条件。首个可测试范围可将需求从 开发完成 推进到 待测试；后续范围或事后补建的范围可在需求已处于 待测试 或 测试中 时继续，不得回退状态。使用 yunxiao_cli_test_scope.py 解析精确需求计划、端标记目录和选定的用例 ID；绝不按标题匹配。只有 YunxiaoQA 可依据真实应用/API/自动化证据更新选定的 TestHub 用例。代码交付或范围任务创建均不要求迭代；仅在正式测试移交时才解析迭代。
9. 将手工用例执行、重测、Bug 关闭、范围证据和需求级测试完成移交给 YunxiaoQA。单个范围完成本身绝不能证明整个需求已完成测试。
10. 运行 实现所有负责人是我的开发任务 时，将其作为稳定批次执行：尝试处理每个已分配的活动开发任务，不得让单个任务级阻塞项中止剩余队列。
11. 运行 修复负责人是我的所有Bug 时，使用官方 CLI 执行冻结批次。预检 Codeup 仓库和分支，在本地验证，按组提交/推送，创建/复用并合并 MR，然后逐个 Bug 验证合并和开发证据。使用 set-status --merge-evidence ... --validation-evidence ... 写入并回读 已修复及待部署/测试移交记录。不得设置 Flow 门槛，也不得使用浏览器/DOM/Cookie 写入回退方案。
12. 对每个具备写入能力的开发、完成和 Bug 节点，都要按 references/change-reporting.md 的要求输出准确执行的操作和完整的任务所属代码文件清单；批次输出必须保留每个任务或 Bug 的归属信息。
13. 收到 处理发布回流：发版任务=<ID> 时，只处理已验证的发布/验收事件和 QA 创建的 Bug 集，按照现有合并提交规则修复冻结的 Bug，按端标记执行一次测试移交（Web 执行一次测试部署 / 小程序 testPipeline=skipped），并将准确的发布修复批次移交给 YunxiaoQA 进行逐个 Bug 重测。
14. 收到 清理分支：发版任务=<ID> 时，要求发布任务在产品验收后处于 已完成 状态，并在清理符合条件的精确 Codeup 分支之前，验证共享的 oneos.product-acceptance/v1 证据；仅 发布完成 时必须阻止清理。尽可能在当前机器上安全清理匹配分支，并报告需要其他开发人员在各自机器上清理的分支。
15. TEMPDEV 工作之后出现正式开发任务或 Bug 时，追加 DELIVERY_ADOPTED，不得重命名或改写 Git 历史。后续开发任务通过 DEVELOPMENT_TASK_AGGREGATED 汇总现有的独立 Bug 分支；每个 Bug 均保留自己的分支、提交、MR 和重测标识。汇总记录发布必须包含的精确分支集合。 此 Skill 不会冒充测试人员：Web 开发侧自动化测试和真实页面检查仅能证明实现已就绪；根据产品规则，小程序跳过这些检查。正式用例执行、当前轮次结果记录、复测、Bug 关闭，以及 待测试→测试中→测试完成 均由 YunxiaoQA 在交接后负责。不得发布到生产环境；将发布操作交给 $yunxiao-release-operations。

跨 Skill 逻辑交接

• 仅接受和输出正式 Skill 名称、精确的需求／交付／开发／测试／发布 ID、实时状态、正式的 ASSOCIATED／TASK_SUB 关系，以及必要的 MR、提交、流水线、部署、证据或幂等性标识符。
• 切勿发现、读取、复制或要求访问其他 Skill 的安装目录。此 Skill 管理其自带资源；缺失的 Yunxiao 上下文必须通过明确的交接 ID 和实时服务解决。
• 下游选择器为 $YunxiaoQA 和 $yunxiao-release-operations；产品退回对象为 $YunxiaoPM。切勿将旧别名或文件系统路径作为命令输出。

强制开发大脑契约

对于每条 $yunxiao-development-delivery 命令，$development-brain 都是必须执行的内部调用，包括查询、计划模式、分配、开发、完成、单项／Bug 批量修复、发布修复和分支清理。此要求并非建议，也不能因为此 Skill 已有「开发复盘」部分而跳过。

1. 开始所选工作前：读取命令后、进行本地代码、Git、Yunxiao、Flow、Codeup 或生产环境写入前，调用其预检。仅提供命令、已知的精确工作项／Bug／发布 ID、发现的仓库／技术范围，以及非敏感的任务／Git／测试证据指针。接收并保留其预检回执。
2. 工作期间：仅应用范围匹配且状态为 confirmed 的回执规则 ID。对于每组实现／修复，记录已应用的 ID，或有证据支持的不适用原因。候选、待定、冲突或过期知识均不能新增要求、扩大差异或为任何写入提供依据。已确认规则发生冲突时，仅在写入前阻止受影响的范围；此 Skill 中的所有常规门禁仍然有效。
3. 工作完成后：在此 Skill 所要求的、基于最终 Git 状态的「开发复盘」和验证证据齐备后，调用 development-brain 进行结束审查。它可以新增一条证据齐全的 candidate；只有在 development-brain 的两个独立任务、评分和安全门禁全部通过时，才能将同一候选规则提升。知识演进只能修改大脑知识和发布包；不得更改业务代码、任务／Bug 状态、Git／MR、流水线或生产环境。新确认的规则仅适用于后续工作或新的预检，不得追溯扩大已完成任务的范围。

故障处理规则明确如下：有效回执中没有匹配的已确认规则时，状态为 无匹配规则，此 Skill 继续遵循自身门禁。知识记录不可读／损坏，或匹配的已确认规则存在冲突时，状态为 安全阻塞：可继续进行诊断性读取，但在修复大脑记录或明确解决冲突前，不得写入代码、Git、Yunxiao、Flow、Codeup 或生产环境。结束审查的知识写入失败不会撤销已完成的交付；应报告 进化未落盘，保留有证据支持的内容和失败原因，绝不得声称内容已保留或确认。

每条最终回复都必须包含：

开发大脑：主动识别|预检通过|无匹配规则|安全阻塞|候选已记录|自动确认已完成|进化未落盘
适用 confirmed 规则/不适用依据：
执行中引用：
复盘候选/待何斐确认：
开发大脑证据：

命令状态契约：

命令	允许的生命周期影响
分配任务	创建或复用 【开发】；编写需求快照和绑定快照的技术计划；【交付】待处理→已分配；需求保持 待开发
开始开发 / 批量开发	重新检查快照是否最新，并且只深度读取任务范围；来源变更时刷新快照/计划；然后将开发子任务从 待处理→处理中，首个子任务还会将 【交付】已分配→处理中，并将需求从 待开发→开发中；写入 【研发启动】
没有正式事项的自然语言开发	首次写入业务代码前，基于已验证的集成基线，为每个代码仓库创建一个 TEMPDEV 交付单元和一个分支实例；不写入云效状态
提交代码	仅在分支与事项匹配或明确重新确认后，才提交/推送/创建 MR；远程回读后，判定完成就绪状态。确认已完成的工作会自动继续，很可能已完成的工作只询问一次，未完成的工作则停止且不更改生命周期。当需要时，执行一次受保护的 Maven API SNAPSHOT 部署，并写入 【代码交付记录】 加 【API包发布记录】
完成开发	在实际验证后完成指定的开发子任务。冻结确切范围并运行 yunxiao_cli_complete_development.py，以便在开发子任务变为 已完成 前，验证唯一的 【测试】 任务、负责人、关联关系和托管描述；然后仅将需求移至 待测试 或保留为 测试中。正式计划使用其选定范围。成功读取但没有关联计划时，跳过正式 TestHub 验证并使用 mandatory-test-task。使用官方 JSON 适配器和固定的 Content-Type 直接读取计划；切勿先探测损坏的计划列表 CLI 或升级其插件。实际发生的可重试 JSON 服务/传输故障会跳过该阶段并显示诊断信息，同时保留强制测试任务。保持 【交付】=处理中
开始修复bug / 完成修复bug / 修复bug	写入开始、交付和完成评论；只有完成操作会将指定 Bug 更改为 已修复；保留 验证人/验证者；绝不移动需求或 【交付】
处理测试修复请求	读取并验证 QA 修复请求评论，追加开发接受意见，然后进入现有修复流程；最终状态为有合并证据时的 已修复，或有审批证据时的 暂不修复
处理发布回流	仅修复由 QA 创建且正式关联到发布事故的 Bugs；只执行一次整合测试部署；不写入生产或产品状态
分支清理	仅更改符合条件的分支；绝不移动工作项

【交付】 是生命周期容器。此 Skill 绝不能执行 【交付】处理中→已完成；该状态转换应由 YunxiaoPM 在生产验收后执行。

分类权限

• audit：仅检查代码资产、状态和日志。
• plan：仅准备任务、分支/MR 计划或修复计划。
• apply：创建或修改指定的开发任务及正式关联关系。
• fix：验证根本原因和范围后编辑代码。
• submit：仅在明确调用的直接 开发任务:任务=<ID> 流程、其已确认且未变更的计划、提交代码、针对指定开发任务的 完成开发、完成修复bug:<BUG-ID>、修复bug:<BUG-ID> 或 修复负责人是我的所有Bug 的最终整合提交阶段内，提交、推送、创建或合并 MR；始终应用受保护的分支与事项匹配规则。此权限还可仅通过 references/api-artifact-publish.md 部署已验证的 Maven API SNAPSHOT 构件；绝不发布正式版构件或生产包。
• cleanup：仅在明确调用 清理分支：发版任务=<ID> 时，删除确切的符合条件的远程分支和安全匹配的本地分支。
• document：生成开发交接文档或诊断报告。 创建 Bug 并不意味着获准修复。通用诊断或代码编辑并不意味着获准提交。开始开发 和 开始修复bug 绝不会授权提交。直接执行 开发任务:任务=<ID>，或确认后未作更改的计划，会授权对指定任务进行受保护的实现、提交、尝试合并和自动完成交接，作为一个完整链条。只有当提交后的分类器返回 confirmed 时，显式执行 提交代码 才会授权同样的自动完成；若返回 likely，则需要针对同一任务进行一次确认；若返回 incomplete，则不得写入任何生命周期状态。完成开发、完成修复bug:<BUG-ID>、修复bug:<BUG-ID> 和 处理测试修复请求：缺陷=<BUG-ID> 仍是有效的指定入口。特殊的测试修复入口必须先验证结构化 QA 请求，且不会放宽分支、验证、MR 或状态证据门槛。完成开发 和一键式 Bug 流程仍受适用的、平台允许的直接合并门槛约束。Bug 批处理仅在冻结队列的编辑循环结束后才授权提交，并且仅限每个仓库与分支组执行一次整合的提交/MR 序列，以及为该批次进行一次兼容的测试部署。只有 清理分支：发版任务=<ID> 才授权删除分支，且范围仅限确切的发布范围，并须满足 references/release-branch-cleanup.md 中的门槛。

对于 UNADOPTED TEMPDEV，诸如“先上测试”这样的明确自然语言请求，会授权向已解析的非受保护 TEMPDEV 分支进行一次受保护的提交/推送，以及一次兼容的测试部署。该请求不授权合并到集成/生产分支、更改正式工作项状态或将代码纳入生产发布。每项此类操作都必须追加本地 COMMIT_RECORDED 和 TEST_DEPLOYMENT_RECORDED 事件，以便后续正式工作项能够接管确切的历史记录。 开发任务:任务=<ID> 输出执行方案 初始仅授予 audit + plan。等待期间不得操作 Yunxiao、创建分支、编辑代码、执行会更改状态的测试操作，也不得将目标标记为已完成。同一 Codex 任务中的明确确认会将权限升级为 apply + fix + submit + direct merge attempt + completion handoff，且仅适用于完全未变更的计划快照。开始开发:任务=<ID> 和 开始修复bug:<BUG-ID> 仅针对指定项目授予 audit + apply：绑定分支、添加开始评论并更改状态，绝不允许编辑代码或提交。开发任务:任务=<ID> 若不带后缀，则在内部分析和各项门禁通过后，直接授予相同的一键权限，不展示计划，也不等待确认。实现、验证和可信版本门禁通过后，必须在内部继续执行 完成开发 执行器，不得要求用户再发一条命令。明确的 提交代码 达到已验证的远程版本后，运行完成就绪分类器：confirmed 时自动继续；likely 时针对准确任务和证据缺口询问一次；incomplete 时停止，不得建议完成。用户对该待处理的同一任务提示回复 是 或 执行完成开发 等内容，即授权完成执行器；无关回复或之后含糊不清的回复不构成授权。完成开发 仍是专用的恢复入口。处理测试修复请求：缺陷=<BUG-ID> 授予受保护的请求受理权限，之后仅针对该 Bug 执行现有的 修复bug 流程；绝不跳过验证、分支绑定、MR 合并或状态证据。完成修复bug:<BUG-ID> 仅针对指定 Bug 授予受保护的 submit + test-deployment coordination 权限；修复bug:<BUG-ID> 则授予完整的 apply + fix + submit + direct merge attempt + test-deployment coordination 一键流程。Bug 批次在编辑循环中针对每个冻结的 Bug 授予 apply + fix，之后按仓库和分支分组，授予一个整合的 submit + direct merge attempt 阶段，并且仅执行一次批次测试部署协调操作；绝不在循环中调用端到端的单 Bug 提交流程。不得检查、等待或将评审批准、CI 结果和讨论解决状态用作 Skill 门禁。绝不执行作者自我批准。在明确启用的隔离快速模式下，若合并仅因评审批准而遭拒，可依据 references/rapid-flow.md，继续使用已验证的远程源提交；其他所有合并拒绝都会阻止流程。这些命令绝不授予生产部署、强制推送、管理员绕过、禁用保护规则、无关重构、冒充测试人员或关闭 Bug 的权限。

执行

所有 Yunxiao Projex、Codeup、Flow 和 AppStack 的发现、状态读取、关系读取、写入、流水线操作、日志读取和回读，都必须使用随附的官方 CLI 适配器。优先使用专用的分配和 Bug 适配器；否则使用 yunxiao_cli_gateway.py。不得使用浏览器、截图/OCR、语义 DOM、Cookie、连接器或网页内部 API 执行 Yunxiao 平台工作，包括在 CLI 失败后将其用作备用方案。仅允许通过浏览器验证正在开发的应用的实际页面；此类验证绝不能作为 Yunxiao 证据。

1. 对于开发任务命令，准确解析项目、需求、编号 【交付】 任务、开发任务、仓库和实际集成分支。对于 Bug 命令，先准确解析 Bug 和项目；Bug 关联关系和仓库字段均为可选输入。
2. 使用明确的 YunxiaoPM 标识符重新读取实时需求和 【交付】 任务。只接受 references/yunxiaopm-handoff.md 中规定的契约；绝不按标题搜索或去重。对于 分配任务，只通过 yunxiao_cli_allocate_task.py 和官方 aliyun devops CLI 执行这些读取。
3. 对于 分配任务，先运行 skill-run yunxiao_cli_allocate_task.py doctor 和 analyze --task ...。优先使用 YunxiaoPM 已留在需求／交付材料中的产品交接快照，并且只将当前开发任务的范围投影到 <需求快照.md>；如果旧版交接没有产品快照，则在此 Skill 内根据权威引用材料重建，并标记为 历史补录。从该任务快照推导 <方案.md>。将用户参数转换为 preflight --task ... --owner ... --plan-start ... --plan-finish ... --requirement-snapshot-file <需求快照.md> --technical-plan-file <方案.md> [--estimated-hours ...] [--development-task ...]。将 任务=<ID> 解释为源 【交付】 任务。验证计划开始时间 ≤ 计划结束时间，并验证可选工时为正数。复用时，如果姓名无法唯一匹配，可保留现有负责人；创建时，如果无法解析负责人，则必须阻止操作，因为官方 CLI 要求提供 assignedTo。
4. 快照投影和旧版重建均为只读操作，不得修改产品资产、代码、分支或 Yunxiao。然后运行带哈希的预检，再运行 apply --preflight <回执>。适配器必须重新预检并拒绝漂移，创建／复用 【开发】<需求标题>，在源交付任务存在优先级时复制该优先级，设置开发者／日期／工时并保持 待处理，创建／读取 PARENT→【交付】 和 ASSOCIATED→需求 关系，并聚合读取所有已写入字段和两个受管区块。源任务缺少优先级时应发出警告，但不得因此阻止其他写入；适配器不得编造业务优先级。复用的开发任务保留原有优先级。只有完成这些操作后，才可将源 【交付】 从 待处理 → 已分配；若状态为 已分配|处理中，则保持幂等；若为 已完成，则阻止操作。绝不使用浏览器／DOM／Cookie 备用方案。
5. 在开发任务描述中更新受管的 ## 开发需求快照 和 ## 技术实施方案 区块，不得覆盖业务内容。两个区块都必须绑定正式需求；方案还必须包含不可变的快照哈希。任一区块都不得包含 Skill 选择器或执行命令。只信任 CLI 应用回执和最终 CLI 回读结果。
6. 分配任务时或从当前对话获取仓库信息均非必需。在 开发任务 阶段，分析需求、受影响的页面／接口／数据、项目配置、现有代码关联、可访问的 Codeup 仓库和当前工作区，自动确定适用的前端／后端项目。对话中未提供仓库地址不会阻止该节点；只有在完成发现后，证据仍然矛盾且无法安全确定修改目标时才停止。
7. 对于直接启动的 开发任务，要求需求状态为 待开发，源交付任务状态为 已分配。对于后续同级任务或事后补录任务，如果确切任务范围和代码目标仍可归属，则接受需求状态为 开发中|开发完成|待测试|测试中、交付任务状态为 处理中；只更新当前开发任务，绝不将需求状态回退。优先复用首次启动记录，但离机完成或历史完成时并非必需。此启动门槛不适用于 完成开发：该命令遵循第 20 步。此处绝不将 已确认／设计完成 更改为 待开发。
8. 对于 开发任务，只读接收时接受明确的工作项 ID，不要求标题带有 【开发】 前缀。优先采用直接需求关系，然后根据官方任务和项目证据解析源需求及范围。在正式开发写入之前，实时交接门槛必须证明任务所属项目及其父交付任务；仅缺少直接需求关联仍可补救，但无法证明或错误的父任务不得以可忽略的可追溯性警告为由放行。根据已解析材料推导 新增 或 优化，以及 前端、后端 或 全栈，绝不能只依据相似标题。 8.1. 先读取分配任务时写入的 ## 开发需求快照，再读取技术方案。将 来源与版本 下列出的每个权威来源与实时 Yunxiao 需求及引用的 PRD／原型逐一比较。若未变化，只深入读取当前任务涉及的章节、页面和交互状态；不要重新加载整个原型或完整 PRD。若有变化，重新执行只读提取，刷新快照，并重新生成与之绑定的技术方案。如果快照暴露出方案遗漏，先修复方案。没有快照的旧任务遵循相同的只读生成流程，并报告兼容性补录，不得仅因缺失而阻止操作。只有会影响验收的规则冲突或必需业务材料无法读取时，才阻止受影响范围；缺少可选哈希、视觉辅助材料或无关链接属于风险，不是硬性门槛。
9. 仅选择一种模式：
   • 开发任务:任务=<ID> 输出执行方案：读取并验证已分配的技术方案，然后验证材料、相关代码和运行时事实。返回 执行前方案复核：复用已存方案，解析代码侧待确认事实，并仅展示差异、缺口、风险和实际执行顺序；在任何写入前停止。保持目标未完成，并等待明确的语义确认，例如 确认按方案执行 ONEOS-789。收到确认后，重新读取已存方案／需求／材料／代码快照；如果任何与执行有关的事实发生变化，则使复核失效，并返回修订后的复核以待确认，而不是执行过时指令。
   • 开发任务:任务=<ID>：不得展示提案或等待确认。验证并复用已分配的技术方案，执行实时材料／代码门槛，列出连续执行任务，并直接执行。不得生成重复的通用方案；只有无分配方案的任务才允许使用旧版备用方案。 确认绝不覆盖尚未解决的强制门槛，也不得扩大已确认范围。
10. 按 references/implementation-materials.md 执行限定范围的写入前材料门槛。优化和新增都必须具备完整、可实施的业务规则和验收标准。只有页面／交互范围才要求唯一可定位的规范原型；仅涉及后端 API、定时任务和数据同步时，使用适用的接口／数据契约及示例，并将原型标记为不适用。引用链接不自动意味着必需材料：必需或影响验收的材料无法读取时，阻止受影响范围；不可用的可选背景／视觉参考只需发出警告。绝不得将已冻结的必需材料降级，以绕过交接门槛。只有本地和在线原型都适用且可用时，才比较两者。
11. 只有材料门槛通过后，才将开发者明确提出或语义明确的实施操作作为权威开始时间。在有专用字段时，只写入一次首次实际开始时间；否则写入仅追加的日志事件。绝不使用分支或提交时间替代，也绝不在重试时覆盖。当没有正式工作项时，将时间保留在本地 TEMPDEV 日志中，直到正式纳入；不得伪造 Yunxiao 评论目标。
12. 自动确定目标项目后，检查其真实仓库配置及集成／默认分支。若存在，前端优先使用 develop、后端优先使用 dev，但缺少任一名称不构成门槛；应使用仓库中已验证的实际集成分支并记录选择结果。在任何业务代码写入之前，每个仓库运行一次 resolve_branch_base.py。常规开发／TEMPDEV 使用已验证的集成基线；通过测试发现的 Bug 使用确切的已部署测试提交；生产热修复使用已验证的生产基线。若测试／生产基线未验证，只能创建临时修复预案，并设置 retestRequired=true，绝不能创建可用于生产的分支。绝不因当前检出的分支已打开，就从该分支创建新分支。
13. 正式工作项优先使用 feature/<WORK-ITEM-ID> 或 fix/<BUG-ID>；无工作项时使用 tempdev/<DELIVERY-UNIT-ID>。一个交付单元可以对应多个按仓库区分的分支实例。对于每个适用的仓库，尝试将代码资产与需求及开发任务关联。若关联方式不受支持、不可用、不明确或回读失败，则记录结果并继续；关联成功与否不是分支、MR、合并或完成门槛。若 Codeup 支持缺陷关联，修复 Bug 时仍必须关联 Bug 本身。TEMPDEV 绝不是正式工作项关联；只有追加并回读 DELIVERY_ADOPTED 后，才可解除其生产限制。
14. 创建或复用分支后，执行 references/dependency-reuse.md 中的只读发现，并在 【研发启动】 中记录选定策略：直接复用、本地存储复用，或说明原因后采用增量安装备用方案。开始开发 和 开始修复bug 在发现后停止，不得运行 Maven／npm／pnpm 安装，不得复制其他工作区的依赖目录，也不得构建项目产物。随后尝试使用原生自动化执行 开发任务：待处理→处理中；对于交付树中首个已启动的子任务，还要执行 【交付】任务：已分配→处理中 和 产品需求：待开发→开发中。自动化缺失、禁用或失败都不是门槛：继续实施，并通过同一授权的状态更新或配置的桥接方式直接更新状态；记录实际方式和结果，不得声称原生自动化已通过。后续同级任务只启动自身的开发任务，不重复更新父任务或需求状态。
15. 首次本地编译、测试或真实页面验证之前，按 references/dependency-reuse.md 应用已记录的依赖策略。只有指纹和运行时门槛均通过时才可复用；否则执行最小且确定的增量安装，并记录实际采用的备用方案。前端范围加载 $apply-oneos-v2-frontend-guidelines，Java 后端范围加载 $alibaba-java-backend-guidelines。编辑前检查仓库事实，并实施已验证材料中的要求。解析源 【交付】 结束标签（Web／小程序；PC 等同于 Web；标签混合或缺失时阻止操作）。Web：针对最终由该任务负责的代码版本，执行适度的自动化验证和真实页面验证；不得将源码检查视为功能或视觉验证。某个工作区启动失败属于本地验证环境问题，不代表 Yunxiao 代码关联或迭代证据缺失。尽可能在同一已验证分支的干净等效工作区验证；如果无法提供最终版本的等效运行环境，则报告 环境阻塞，不得将事项发给 YunxiaoPM 修复关联关系。小程序：跳过开发者自测用例、自动化测试和真实页面验证；在回复中记录跳过情况。
16. 对于 Web 需求，实施后完成开发者侧验证：针对已实现版本执行编译／静态检查、单元／集成测试和适度的真实页面检查。开发者发现的问题须在同一范围内修复。对于 小程序，跳过这些开发者侧测试。不得创建正式测试运行、填写测试人员结果、关闭 Bug 或推进测试阶段的需求状态。
17. 开发任务 的实施在代码通过验证且任务证据完备后完成。Web 还要求完成开发者侧验证。正式 QA 执行在后续进行，但只有在唯一的 【测试】 任务已就绪并经过官方回读后，完成开发 才可关闭开发工作项。
18. 当 开发任务 的实施子阶段通过时，写入包含 $yunxiao-development-delivery 和 完成开发:任务=<开发任务编号> 的受管下一阶段区块。在直接一键模式下，在已授予的同一任务权限范围内，内部继续执行受保护的 提交代码 和完成执行器；实施子阶段本身不会绕过这些节点。仅方案模式仍须在写入前停止，单独的 开始开发 不授予代码提交权限。任何模式都不授予生产部署权限。
19. 对于批处理命令，执行 references/batch-execution.md：解析当前账号，冻结并展示活动任务快照，在隔离工作树中依次调用相同的单任务处理器，记录每项任务的活动时长片段和停止原因，并继续处理。任务级停止绝不授权绕过其门槛。
20. 对于 完成开发，存在匹配的 开发任务 执行证据时应检查，但代码验证、受保护提交、MR 复用／创建、合并尝试、任务关闭或测试范围交接均不得以执行证据缺失／不完整、代码资产关联、开始状态不匹配或本机无开始时间作为门槛。若现有提交、已合并 MR 或集成版本能唯一证明代码已交付，则接受事后补录任务。只执行确实缺失的材料分析、实施或验证；不得重建已交付的代码、提交或 MR。绝不伪造历史开始时间或工时：记录 工时无可核验来源 并继续。Web：针对最终代码进行新的开发者侧完成验证，并在声明验证通过前解决开发者发现的所有阻塞问题。若运行环境不可用，保留已证实的代码交付，可以创建／复用限定范围的 QA 证据存放位置，但必须将验证标记为受阻，不得声称已达到测试就绪状态。小程序：跳过此完成复验。不得伪造正式 QA 证据。
21. 完成验证通过后，先 fetch/pull；若发生代码冲突，只停止冲突仓库。对于仍未提交的变更，重新执行限定范围的验证，然后创建／复用一份 oneos.delivery-submission-attempt/v1，并使每个仓库从其最近已验证检查点继续。提交消息和所有日志变更摘要都必须使用中文。根据 references/api-artifact-publish.md 发布符合条件的 Maven API SNAPSHOT 制品，推送，并为每个适用仓库创建或复用 MR。某仓库已成功后，即使后续仓库失败，也绝不重复该仓库的操作。对于事后补录任务，读取并验证所有现有提交／MR／集成版本；必要时追加 EXTERNAL_COMMIT_DISCOVERED。如果已有可信交付，则不创建任何内容。在此 MR 节点不得读取、要求、写入或推断迭代／Sprint。尝试将每个 MR 与需求及开发任务关联；无论结果如何，都按关系记录 associated 或 skipped/failed 并继续。只有流水线身份、范围、API 包新鲜度和部署基线均已验证后，才可运行测试流水线；生产流水线和发布仓库不在此 Skill 范围内。代码交付经过官方回读后，对 testDeliveryMode 分类：明确选择 execute 时运行独立测试流水线执行器，并要求回读部署版本；明确选择 merge_only 时，凭已合并代码证据完成并记录待部署／待测试交接；未选择时询问一次并提供两个选项。classify_completion_readiness.py 输出 auto_complete_and_test、auto_complete_merge_only 或 ask_test_delivery。硬性阻塞项仍会阻止所有完成写入。
22. 不得检查或等待 Codeup 审核批准、CI 状态或讨论解决情况。创建 MR 后，立即尝试将其合并到仓库中已验证的实际集成分支。绝不执行作者自我批准。常规模式要求平台接受合并。每次成功合并后，更新并回读同一份 【代码交付记录】，其中包含仓库、源／目标分支、提交 SHA、MR ID／URL、合并状态和合并时间；开发任务标记为 已完成 前，必须完成此回读。在明确启用的隔离快速模式中，如果拒绝原因仅为审核人批准要求或作者自审限制，则只记录一次，并按照 references/rapid-flow.md 将已验证的远程源提交作为交付版本；同时记录 MR 仍处于打开状态。绝不强制推送、使用管理员绕过或禁用保护规则。
23. 每个适用仓库的交付版本通过验证后，执行 references/codex-time-accounting.md。只有首次开始的不可变证据、唯一关联的 Codex 时长、操作者和精度均可审计时，才计算并写入实际工时。任何输入不可用时，准确记录缺失项和 工时无可核验来源；绝不用计划工时、对话墙钟时长或其他任务的记录替代。
24. 工时输入可审计时，通过 projex-create-effort-record 或 projex-update-effort-record 准备一笔幂等的实际工时事务。否则省略可选工时阶段，并记录 工时无可核验来源。此时不要关闭开发工作项。
25. 冻结 oneos.complete-development-plan/v1 计划，并运行 skill-run yunxiao_cli_complete_development.py preflight --plan <计划JSON> --output <预检回执JSON>，随后运行 apply --preflight <预检回执JSON> --output <执行回执JSON>。固定顺序为：可选工时 → 必需测试交接 → 开发任务 已完成 → 可选需求 开发完成→待测试 → 最终回读。在关闭开发任务之前，测试交接阶段必须已证明唯一测试任务的负责人、受管范围、TASK_SUB 父任务和 ASSOCIATED 需求。两个命令都不会读取其他生命周期 Skill 的安装情况，也不要求其版本一致。既有交接、可信版本、验证、授权和回读门槛仍为强制要求。关键阶段失败时写入部分回执并停止后续阶段；重跑时只从已完成的阶段边界恢复。详情：references/complete-development-executor.md。 25.1. 保持源 【交付】 任务处于 处理中。执行器运行当前范围前，不得要求同级开发任务完成或其工时记录齐备。首个可测试范围可以将需求从 开发中 推进至 开发完成→待测试；后续范围在需求已处于 待测试|测试中 时应幂等执行，绝不回退状态。同级任务完成情况仅用于汇总报告。交付任务是跨阶段容器，只能由 YunxiaoPM 在生产验收后关闭。
26. 创建或复用 【测试】 任务前，根据开发任务和需求交接解析确切的源 【交付】 任务，然后读取当前项目的角色成员，并要求恰好有一名用户担任 测试主管。在同一项目、需求和交付树下查找现有有效测试任务；绝不只按标题去重。角色读取失败、主管数量为零或超过一名、测试任务存在多个且有歧义，或无法解析交付任务时，只阻止测试交接阶段：不得创建新测试任务，也不得将需求推进到 待测试。
27. 将新建的 【测试】 任务直接置于源 【交付】 任务下，或将唯一可复用任务设为该交付任务的子任务。要求并回读两项正式关系：【测试】 TASK_SUB→【交付】 和 【测试】 ASSOCIATED→产品需求。如果可复用的顶层任务没有歧义，可以附加；如果任务已属于不同交付任务，则不得解除其关系或悄悄移动，并阻止交接。必须明确将负责人设为已解析的测试主管，不得沿用创建者、父任务负责人、交付负责人、开发者或平台默认值；可复用任务当前负责人不是测试主管时，必须替换。
28. 在新建或复用的测试任务描述中，以幂等方式更新受管的 ## 开发交接 区块，并且恰好包含两个子章节：### 测试建议 和 ### 临时需求变更点。以原生 Markdown 和实际换行及列表项写入可见交接内容；强制设置 formatType=MARKDOWN。绝不得在可见描述中写入字面量 <br/>、HTML 标题、<pre> 或原始 JSON。机器数据仅限隐藏 HTML 注释格式中的 oneos.test-scope/v1。根据需求、实现、变更的接口／数据／权限、验证证据、相关 Bug、MR、环境前置条件、边界路径和回归范围推导具体测试建议；绝不使用“全面测试”等没有具体内容的表述。仅记录已明确确认偏离原始需求的变更作为临时变更，并包括行为变更、原始行为、原因、确认依据、影响和已知的后续事项。若无此类变更，写入 - 无（本次开发未发生已确认的临时需求变更）。保留受管区块以外所有人工编写的描述；重试时替换原区块，不得重复创建。若尚未确认的候选变更会影响验收，则阻止测试交接，不得将其记录为已确认变更。
29. 回读测试任务的 TASK_SUB 父任务 ID、ASSOCIATED 需求 ID、负责人用户 ID、两个受管标题及其实际内容。父任务 ID 必须等于源交付任务 ID，需求 ID 必须等于源产品需求 ID。任何关系、负责人或描述写入／回读不匹配都会阻止测试交接。
30. 只有第 29 步通过后，专用执行器才执行开发任务关闭操作；随后在实时工作流仍要求时，单独将需求推进至 待测试 并回读所有目标对象。若需求已处于 待测试 或 测试中，则将其视为幂等续行，不得回退。完成流程必须携带明确的测试交付选择：确认流水线身份和部署基线后，execute 才调用独立测试流水线执行器；merge_only 不运行流水线，并记录 待部署、待交付测试；未选择时，在 MR 合并后询问一次。只有实际已部署版本包含已合并修订内容时，成功的流水线才可作为证据。输出包含当前范围和所选状态的正式交接；不得伪造测试结果。
31. 对于常规开发完成，不得发现、启动、附加或写入 oneos.test-deployment/v1。Web 测试流水线执行不属于常规开发完成操作；小程序没有云端测试流水线操作。 32.1. 所有完成操作和必需回读结束后，仅回顾当前开发任务最终 Git／MR 文件清单。输出 开发复盘，包含 修改内容 和 修改原因；原因必须依据需求、Bug、任务方案、提交／MR 和实际代码证据推导。不得编造原因、包含无关文件或因复盘执行新的写入操作。
32. 对于 修复bug:<BUG-ID>，准确解析 Bug，并要求其处于可由开发者处理的非终态；Bug 负责人可以是任意用户，不得隐式重新分配。若存在正式关联项、需求、开发任务、失败用例和仓库关系，则读取这些关系，但允许关联项为零且没有仓库元数据。根据活动工作区、Bug 描述、复现路径、页面 URL 或接口、运行时证据和当前对话确定目标代码库。只有缺少复现输入、修复范围或目标环境，或者证据冲突导致无法安全确定修改目标时，才在代码写入前停止。开发者不得仅为推导验证人而读取创建者，且绝不得更改 验证人/验证者。
33. 对每个受影响的仓库独立选择修复分支。若 Bug 有关联项，则沿其正式关系查找底层需求，然后检查该需求及其开发任务，寻找一个远程已存在、可写、安全同步且正式关联到同一仓库的开发分支。只有唯一解析出有效分支时才复用。若关联开发分支缺失、不止一个、不可写、无法同步或存在冲突，则阻止所有写入；对于有关联项的 Bug，绝不创建 fix/<BUG-ID>。只有已证明没有任何正式关联项的 Bug，才可基于仓库中已验证的实际集成分支创建或复用自身的 fix/<BUG-ID>。绝不只依据标题／名称相似度选择分支。将所选分支和后续 MR 与 Bug 本身关联，并保留独立证明的需求／开发任务／失败用例关系，不得编造缺失关系。
34. 复现 Bug，实施范围内最小修复，并验证失败路径、边界及相邻路径。在同一个单 Bug 节点中持续处理：获取最新代码、重新执行限定范围的验证、提交、推送、创建或复用 MR，并立即尝试将 MR 合并到已验证的集成分支。不得检查或等待审核批准、CI 状态或讨论解决情况，也不得执行作者自我批准。代码冲突、目标分支错误、技术上无法合并的 MR 或平台拒绝，都必须使该 Bug 停止，不得绕过保护措施。
35. 只有在限定范围的开发验证通过，且确切 MR 已通过官方回读确认为 MERGED 并具有可验证的 mergedRevision 后，才可完成单个 Bug。写入 【研发完成】 记录，其中包含修复摘要、验证结果、仓库、目标分支、MR 和合并提交，并明确标注 待部署、待交付测试。只将 Bug 设为 已修复，保留验证人和负责人，然后回读状态和记录。记录格式及证据检查定义于 references/yunxiao-cli-bug-batch.md；单 Bug 流程采用相同证据要求，但不更改其现有负责人策略。此处无需测试部署；QA 必须先验证实际已部署版本，才能复测或关闭。
36. 对于 修复负责人是我的所有Bug，运行 doctor --require-auth，冻结当前项目／当前用户的确切 Bug 快照，按第 34 步解析仓库和分支，并创建 oneos.yunxiao-cli-bug-delivery-plan/v2。代码写入前运行 preflight，验证 Codeup ID、权限、分支和基线证据。Flow 可用性、触发模式、流水线数量和测试部署均不是修复门槛。绝不绕过 CLI 身份验证或 Codeup 保护措施。
37. 运行 ensure-branches --preflight <回执>，使 Codeup 分支创建／复用及回读通过 CLI 完成。随后循环处理可处理的 Bug：当实时状态必须进入实际进行中状态时，使用 yunxiao_cli_bug_batch.py set-status；在本地编辑和验证，并记录每个 Bug 的差异边界。循环内不得提交、推送、创建 MR、合并或部署。按确切的仓库和所选目标分支对工作区分组，绝不混入无关的既有变更。
38. 本地和合并验证通过后，协调各分组，每组最多创建一个本地提交并推送一次，然后记录远程提交映射。运行 ensure-mrs，再运行 merge-mrs，通过 CLI 创建／复用、关联、合并并回读确切 MR。合并执行器会在合并前再次检查源提交。某分组失败时，阻止受影响的 Bug；之后不自动运行测试流水线。
39. 将实际开发验证证据构建为 oneos.bug-development-validation/v1，其中包含每个 Bug／分组的版本、通过的检查、修复摘要和带哈希的本地报告。将其与 CLI 合并回执一并传给 set-status --snapshot <快照> --target 已修复 --merge-evidence <合并回执> --validation-evidence <验证清单> --serial <BUG-ID>...。写入前重新读取每个 MR，写入后验证状态、负责人、验证人和受管描述记录。缺少或无效的合并／验证证据会阻止写入；Flow 缺失不会。记录须注明待部署、待测试交接和 qaReady=false。状态写入失败时，不得重复 Git 操作。
40. 对于 处理发布回流：发版任务=<ID>，执行 references/test-deployment-handoff.md：验证发布事故及回滚／验收证据，要求 QA 创建的 Bug 集合，复用统一的 Bug 修复流程，在测试环境部署一次，并输出 验证发布回流；绝不启动生产环境或跳过 QA 复测。
41. 对于 分配任务、开发任务、批量开发、完成开发、单 Bug 修复、批量 Bug 修复或发布修复，在最终回复前执行 references/change-reporting.md。写入前记录仓库基线，从实时 Git 证据推导文件清单，区分计划变更与实际变更；即使被阻止，也必须输出 实际执行操作 和 实际代码变更。缺少这些章节时，不得报告节点或批次已完成。
42. 对于 清理分支：发版任务=<ID>，执行 references/release-branch-cleanup.md。重新读取发版任务，要求状态为 已完成，验证产品验收证据和不可变的生产锚点，根据可信的任务／Bug／MR 关系推导候选分支，应用保留规则和逐分支安全门槛，删除符合条件的确切远程分支并回读，且仅执行安全的本机本地清理。绝不更改发布、需求、任务或 Bug 状态。已不存在的分支视为幂等成功；其他开发者的本地分支须报告为需要在其机器上运行同一命令。

Non-negotiable gates

• 标签是模块元数据，不能用来标识开发身份。
• 创建开发子任务和进行批量发现时使用 【开发】 前缀，但显式调用 开发任务:任务=<ID> 时，不要求该前缀或子任务类型。
• 每条命令都有前置条件门槛。若检查失败，不得执行任何状态变更操作，并须返回失败的检查项、实时值、预期值、影响以及确切的补救措施或下一条命令。
• 批量执行可以在某个任务失败后继续，但不得让该任务越过失败的门槛继续执行。
• 批量 Bug 执行可以在某个 Bug 失败后继续，但不得让该 Bug 越过失败的门槛继续执行。
• 实施前冻结批量任务列表。不得悄悄添加运行期间分配的任务。
• 有明确开发意图但没有唯一正式事项时，不是死门槛：首次写入业务代码前，创建本地 TEMPDEV 交付单元和安全分支。仅在明确请求测试操作时，才可推送到非受保护的临时分支并部署到测试环境。在被一个正式任务、Bug 或获批的技术改进事项采纳前，不得将其纳入生产合并计划。
• 后续正式事项通过只追加证据的方式采纳 TEMPDEV；不得重命名旧分支、改写提交历史，也不得仅为让标识看起来正确而重复提交。多个 TEMPDEV／独立 Bug 分支可以映射到同一个开发任务，并作为独立发布输入保留。
• 新增 oneos.delivery-ledger/v1 注释和完整开发执行器校验受支持的数据架构和真实任务证据，不校验其他角色的本地安装。开发者机器上缺少或安装了不同版本的 YunxiaoPM、YunxiaoQA 或发布 Skills，不构成阻塞。计划和事件中的 suiteVersion 标识数据生产者，不表示已安装五个 Skills。现有开发大脑预检保持不变；移除这项检查不会打包或豁免该独立依赖。
• 每个批量任务都使用隔离的 worktree 或等效工作区；绝不混合不同任务尚未提交的更改。
• 不得在 worktree 之间复制、绑定挂载或直接共享 node_modules、target、dist 或其他分支构建输出。运行时在当前机器上解析 Maven 和 pnpm 缓存目录；绝不假设用户主目录的默认路径。仅允许在本地真实验证前，将依赖下载作为文档所述的增量安装备用方案；不得将其作为创建分支的副作用。
• 对于 Bug 批次，按完全相同的仓库和所选目标分支分组 worktree。只有在差异边界仍可审计时，多个已冻结 Bug 才可有意共用一个组；绝不得将开发任务、不相关 Bug 或用户已有更改混入该工作区。
• 只要仍有快照任务尚未实施或被阻塞，就不得将批量目标标记为完成。
• 在 分配任务 中，任务=<ID> 始终表示源 【交付】 任务，而非开发子任务。
• 分配任务 必须先写入需求快照，再写入绑定该快照的技术计划。旧任务缺少快照时，可在 开始开发 时补救；不得将其设为无条件的生命周期阻塞项。
• 分配任务 必须对所有云效读写操作，通过官方 aliyun devops CLI 使用 yunxiao_cli_allocate_task.py。缺少 CLI／插件／PAT／组织 ID、预检指纹已变更或创建时责任人不明确，均属于零写入阻塞；绝不得回退到浏览器／DOM／Cookie 操作，也不得泄露凭据。
• 不得更改 【交付】 任务通过官方回读确认的当前负责人，也不得覆盖其计划日期或预估工时。本 Skill 仅负责 待处理 → 已分配 → 处理中；处理中→已完成 属于 YunxiaoPM 中发布后的产品验收。
• 如果引用的 【交付】 已是 已完成，不得创建或重新打开开发或测试子任务，也不得回退任何状态。验收后的新变更必须返回 YunxiaoPM，开启新的需求／交付生命周期。
• 分配时必须同时尝试 TASK_SUB→【交付】 和 ASSOCIATED→需求。缺少分支／代码／MR 关联结果时，记为可追溯性警告。正式开发开始／完成则不同：官方任务所属项目和唯一父级交付必须与已冻结的交接一致；若详情未提供父级关系，须读取官方父级关系；无法证明该身份时停止。绝不得将可选的代码资产关联与强制的业务范围身份混淆。
• 托管的下一阶段描述块必须具备幂等性，不得覆盖人工撰写的描述内容。
• 根据需求、任务、项目、Codeup、运行时和工作区证据，自动推导类型、范围、目标项目、仓库和实际集成分支。绝不得要求用户在对话中提供仓库地址。
• 开发任务 只接受 任务=<开发任务编号>，以及可选的字面后缀 输出执行方案。不得要求或鼓励使用 类型=、仓库=、前端仓库=、后端仓库=、范围= 或 基线=。
• 方案模式在获得针对同一任务的明确确认前只读。等待确认时，目标保持未完成；不得仅因等待确认就将其标记为完成或阻塞。
• 直接模式只跳过方案展示和确认；绝不跳过需求／材料、状态、仓库、实施或验证门槛。
• 执行已确认的方案前，重新读取方案输入。任何与执行相关的变更都会使确认失效，并要求修订方案。
• 方案模式必须将操作和代码部分标记为计划中、尚未执行。确认后，以实际证据替换；绝不得将提案描述为已完成工作。
• 每个具备写入能力的节点都必须报告 实际执行操作 和 实际代码变更。使用 Git 状态／差异／提交／MR 证据，并列出任务涉及的每个新增、修改、删除或重命名文件，包括其行为、原因、行数和验证情况。
• 记录写入前的仓库基线，并排除无关的既有未提交文件。绝不得将其他任务或用户已有的更改归为当前任务所有。
• 批量开发和批量 Bug 修复必须为每个事项重复记录操作台账和代码清单。汇总计数不能取代逐项详情。
• 被阻塞的节点仍须报告已完成的操作、当前由任务负责的差异、尚未执行的操作、保留的 worktree／分支以及继续执行的条件。
• 如果代码没有变化，须写明 代码变更：无，并提供有证据支持的原因。除非已证明解决方案属于配置、数据、环境或确实无需改代码，否则不得声称代码实施或代码缺陷修复已完成。
• 优先使用前端=develop、后端=dev，但缺少这些分支并非门槛；使用仓库中经验证的实际集成分支。
• 分支关联自动化缺失或失败不是门槛。记录状态变更是原生、桥接还是直接执行。
• 优化需求的描述为空、不可读、为占位文本或含义不明确时，必须停止并指出具体缺失信息。
• 新需求必须包含完整的业务规则和验收规则。页面／交互范围还必须提供一个规范原型；非 UI 范围必须提供适用的 API／数据／状态契约及示例，不得捏造 UI 原型。缺少重复附件、可选视觉辅助材料或背景链接不会阻塞。必需材料缺失以及影响实施／验收的关键冲突，仍会阻止受影响的范围；须保留已冻结交接中声明的必需项。
• Web 开发任务必须针对已实施版本完成适当的开发者侧自动化和真实页面验证，方可完成；小程序开发任务则记录跳过原因。此证据（或跳过说明）不是正式 QA 计划、用例执行、报告或验收结果。
• 完成开发：Web 必须重新运行全新的开发者侧完成验证，不得复用首次验证记录；小程序跳过该次重新验证并记录原因。
• 开发者发现的失败仍属于开发范围；正式 Bug 创建、复测、关闭和测试证据须在移交测试后遵循 YunxiaoQA 流程。
• 创建或复用 【测试】 与将需求从 开发完成 → 待测试 分别是两个经验证的操作。测试任务必须是准确源 【交付】 任务的正式 TASK_SUB 子任务，并与源需求建立 ASSOCIATED 关联。必须通过回读确认这两个关联 ID、唯一的项目 测试主管、责任人角色一致以及托管描述。
• 完成开发 生命周期写入必须通过 yunxiao_cli_complete_development.py 执行。该执行器禁止 lightweight-verification，要求可信的交付版本和开发验证证据，限制每个阶段的写入操作白名单，并且在验证测试任务就绪前不会执行开发状态更新。
• 提交、推送、创建／合并 MR、实际工时回写、完成开发任务、创建测试任务或执行 开发完成 → 待测试，均不得要求迭代／Sprint、测试流水线或 oneos.test-deployment/v1。
• Web 测试流水线是预先创建的平台配置，仅与 Bug 测试部署或其他明确授权的测试流水线节点有关。根据完全匹配的 Codeup 源分支、目标分支、部署目标和逻辑测试环境解析；流水线名称仅作提示，不必包含 test/测试。不得通过本 Skill 创建、复制、更新、重命名或删除 Flow 流水线或服务连接；匹配结果为零个或多个时，仅阻塞依赖该流水线的节点。小程序不发现或启动测试流水线。
• 绝不得将新创建的测试任务留在项目顶层。仅当可明确确定其需求和交付时，才可附加可复用的顶层测试任务；绝不得将任务从其他交付树中分离或暗中重新指定父级。
• 托管的 ## 开发交接 块必须具备幂等性，并保留其外部由人工撰写的描述。绝不得捏造临时需求变更；未经明确确认的验收相关变更会阻塞交接。
• 开发可以将 Bug 标记为 已修复，但不得关闭 Bug 或写入通过的复测结果；只有 YunxiaoQA 才能根据复测证据执行这些操作。
• 计划日期和预估工时属于排期数据，不能证明实际已开始开发。
• YunxiaoPM 是唯一的产品阶段入口。本 Skill 不得将 已确认 或 设计完成 接受为开发入口。
• YunxiaoPM 交接有意不包含 【开发】 或 【测试】 任务。缺少这些任务不属于交接失败。
• 开发入口阶段绝不得创建第二个 【交付】 任务，也不得重新创建缺失的分析／设计任务。
• 快速通道或编号推进式交接可以合理地不包含分析任务或设计任务。
• 【交付】 描述为占位内容表示明确的产品风险，并不能证明设计已完成。
• 提交不能证明开发已完成。有意不将评审批准、CI 状态和讨论解决情况设为合并门槛。仅当无冲突、技术上可合并，且在当前权限和保护设置下被 Codeup 接受时，MR 才可合并到经验证的实际集成分支。
• 分支和 MR 与需求及开发任务的关联按尽力而为处理。对每个适用的仓库都应尝试并记录结果；若不受支持或失败，则继续执行。
• 绝不得执行作者自我批准。Skill 可以在不等待可选评审的情况下尝试合并，但 Codeup 的保护和权限始终具有决定权。
• 涉及单个仓库的需求不得等待明确不适用的仓库；涉及多个仓库的需求不得提前结束。
• 已修复 表示代码修复已验证并合并。这不代表已部署或已准备好复测；在单独经验证的测试交付之前，保持 待部署、待交付测试。
• 单 Bug 一键命令在 $yunxiao-development-delivery 之后必须严格为 修复bug:<BUG-ID>；该命令依次执行 开始修复bug、修复与验证、提交代码 和 完成修复bug。拆分命令仍可供开发者主导编码时使用；旧命令 接收Bug 已弃用，Bug修复完成 已更名为 完成修复bug。
• 规范的 Bug 批量命令是在 $yunxiao-development-delivery 之后执行的 修复负责人是我的所有Bug。接受含义明确的等效命令，但始终须冻结并展示列表；循环中不得调用端到端的单 Bug 提交／部署处理程序。
• 单 Bug 命令可修复任何用户负责的 Bug。绝不得隐式重新指派；保留并报告实时负责人。
• Bug 可以没有任何关联项，也可以没有仓库信息。缺少仓库信息不是修复门槛。若有一个或多个正式关联项，则沿关联项追溯到需求，并复用唯一一个经验证、可写且可同步的开发分支；分支缺失、多个或不安全时，须以零写入方式阻塞。只有已证明没有关联项的 Bug，才可从经验证的集成分支创建或复用 fix/<BUG-ID>。始终将所选分支／MR 资产与 Bug 本身关联；若无法安全确定修改目标，则停止。
• 开发绝不得设置、清除、替换 Bug 的 验证人/验证者，也不得以该字段作为完成门槛。Bug 创建时由 YunxiaoQA 将该字段设为当前测试用户；开发在单项和批量修复期间均须保留该值。
• Bug 批次在编辑循环中不得执行任何提交、推送、MR、合并或部署。组合验证后，每组只提交和合并一次。Web 和小程序均以已合并代码证据和待部署／待交付测试交接作为修复终点；不得自动执行 Flow 操作。
• 使用随附的官方 CLI 适配器解析当前用户、读取快照／状态／回读，以及操作 Codeup 分支／MR／合并。认证、项目身份、不安全分支和代码版本不一致仍会阻塞受影响的操作。Flow 配置或运行可用性不会阻塞修复完成。绝不得泄露凭据，也不得绕过 CLI 使用浏览器／Cookie 写入。
• 任何开发或 Bug 命令都不需要用户在对话中提供仓库地址；根据工作项和代码／运行时证据自动确定目标项目。
• 清理分支 要求提供一个准确的 发版任务 ID，实时状态为 已完成，且有效、通过的 oneos.product-acceptance/v1 证据在发布任务、范围内需求和源交付任务之间保持一致。状态为 发布完成 意味着产品验收仍待处理，必须不删除任何分支。发布失败、验收证据失败／缺失／不一致、回滚／状态不确定、缺少不可变的生产锚点、范围不明确、关联／MR 证据不足或未达到保留要求时，须保留受影响分支并说明原因。
• 分支名称仅是发现提示，绝不是删除证明。绝不得删除默认分支、受保护分支、集成分支或长期分支；绝不得使用通配符删除、强制推送、git branch -D、管理员绕过或修改保护规则。
• 远程清理和本地清理是两项独立操作。本 Skill 只能清理当前 Codeup 远程分支，以及仅在其运行机器上的安全本地分支；无法删除其他开发者计算机上的分支。
• 没有开发验证及实际合并 MR／版本证据时，绝不得将 Bug 设为 已修复。不得关闭 Bug 或声称复测通过；部署验证、复测和关闭仍由后续测试交付和 YunxiaoQA 负责。
• 实际工时证据独立于代码交付和生命周期关闭。仅在来源数据可审计时才写入并回读工时记录；否则记录 工时无可核验来源，不创建工时记录，并继续当前任务经验证的关闭和测试交接流程。
• 正常模式使用最新适用 MR 的 merged_at 作为精确完成时间；隔离式快速模式使用可信的远程交付提交时间；不得以命令执行时间、首次提交时间、首次 MR 合并时间或仅含日期的工作区间代替。
• 每当建立唯一开发任务上下文时，即使用户未使用标准命令，也要自动维护 oneos.codex-task-segment/v1。完成时，按开发任务 ID 查询，再使用正式 Bug／MR／提交／分支关联以及有界的开始至完成元数据时间窗口，仅修复缺失关联；只深读元数据命中项，正常路径绝不完整扫描所有对话。
• 只统计与开发任务存在唯一、可审计关联的 Codex 任务或逐项片段。按 Codex 任务 ID 加片段 ID 去重；绝不得将未分段的多任务对话整体归入多个开发任务。存在冲突或无法拆分的共享片段时，归为 未归属；不得要求开发者选择、分类或确认。
• 先对原始活动耗时秒数求和，再一次性四舍五入为分钟。按 计算工时 = 总分钟数 ÷ 60 换算，并以四舍五入方式保留两位小数作为源值。将该值写入工时记录；如果云效将其确定性地规范为项目配置的精度（例如 0.28 → 0.3），则在工作描述中同时保留计算值和回读值，并只将回读值作为平台记录。审计证据中保留整数分钟数和未经舍入的计算值。
• 如果无法验证活动耗时、关联证据、工时记录精度、工作日期范围、精确时间戳描述、操作人或回读结果，则跳过工时写入并报告缺失证据。绝不得以首条消息至末条消息的墙钟时长或计划工时代替，也不得因此阻塞无关的代码、任务状态或测试交接操作。
• 每条生成的下一阶段命令都必须以明确的 $<skill-name> 选择器开头。
• 绝不得通过此 Skill 修改生产流水线。
• Maven API 构件自动化只能向已配置的快照仓库发布经过验证的 -SNAPSHOT 坐标。缺少／无效的快照仓库配置、发布坐标、无法读取消费者重新解析结果、存在重复但不确定的发布，或无法证明流水线刷新策略，都会阻塞 API 包或依赖流水线的节点；绝不得回退到发布仓库或生产包，也不得盲目重试。
• 缺少 CLI／插件／PAT／组织或端点能力通常属于零写入阻塞，绝不授权使用视觉或浏览器回退。唯一范围明确的传输例外是在 完成开发 期间发现 TestHub 计划：默认直接使用官方 ListTestPlan JSON 适配器；已知的 CLI Content-Type 缺陷绝不得触发探测或插件升级。实际可重试的 JSON 服务／传输错误须记录 plan-read-skipped，仅跳过正式计划／用例验证，同时继续强制执行测试任务交接。认证、授权、参数、所属关系及歧义问题仍属于阻塞项。

Return

执行结论：完成|部分完成|阻塞|仅输出方案
项目/迭代：
需求/交付任务/开发任务：
测试任务/父交付任务/关联需求：
TestHub计划读取：JSON直接读取成功|JSON读取失败后跳过（真实错误/traceId）；不探测旧CLI，不触发插件升级
正式测试计划验证：已冻结用例|已跳过（无关联计划|端侧未配置|范围为空|官方JSON读取失败）
负责人/计划开始/计划完成/预计工时：
真实开始时间：
实际完成时间：
工作日期/工作日志ID：
Codex关联任务/分段：
Codex查找范围/分段结果：
Codex总时长（分钟）：
实际工时（小时）：
仓库/分支/MR：
Bug负责人/状态：
批量提交组/test部署执行ID：
发版任务/生产版本锚点：
分支清理结果（远程/本机/其他开发机待处理）：
状态变化：
实际执行操作：
1. <系统> <对象> <操作> <变更前→变更后> <结果/证据>
实际代码变更：
- <仓库>/<分支> [新增|修改|删除|重命名] <文件> <代码位置> <修改内容和原因> <+N/-N> <验证>
开发大脑：
- 预检：
- 适用 confirmed 规则/不适用依据：
- 执行中引用：
- 复盘候选/待何斐确认：
- 证据：
开发复盘（仅完成开发）：
- 修改内容：
- 修改原因：
未执行操作及原因：
门禁结果：
验证：
开发验证/剩余阻塞：
测试建议：
临时需求变更点：
未完成仓库或阻塞：
下一责任角色：
下一条口令：