Yunxiao Development Delivery

---
name: yunxiao-development-delivery
description: >-
  云效开发交付与代码实现。用户即使没有写 $yunxiao-development-delivery 或标准口令，只要自然语言明确表达
  查看、领取、分配、开始、实现、提交、完成开发任务，修复本人或指定Bug，处理发布回流或清理发版分支，
  就主动识别为开发意图；先通过官方 aliyun devops CLI 唯一定位【交付】、【开发】或Bug，再规范化为内部动作。
  无唯一正式事项但开发意图明确时，在首次业务代码写入前创建可追溯TEMPDEV分支，不阻止编码和test验证；正式推生产前必须完成认领与冻结。
  多候选或证据冲突时只阻断受影响仓库，不按标题猜编号，不静默写云效。通用的本地代码测试、正式QA测试任务、产品需求和生产发布不应触发本Skill。
  所有平台写入继续使用快照、哈希预检、漂移检查、单次写入、定向回读和幂等回执；禁止浏览器、DOM、Cookie和网页内部接口回退。
---

# Yunxiao Development Delivery

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

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

```text
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、业务仓、云效数据、流水线或生产环境。不得手工伪造或提前写入每日成功状态。

Operate development tasks and Codeup assets without using code activity as a substitute for real work state. Suite version: `10.0.0`.

## Load the required references

Read each selected file completely before acting:

- Development task, Codeup, stage-task and OneOS controls: [references/controls.md](references/controls.md).
- Short Chinese commands and defect-fix workflow: [references/commands.md](references/commands.md).
- For implicit invocation, natural-language normalization, unique task selection, and development-versus-test disambiguation, read [references/semantic-routing.md](references/semantic-routing.md) completely before selecting a command.
- `开发任务:任务=<ID>` direct/plan modes, 新增/优化材料门禁, prototype comparison, and implementation completion: [references/implementation-materials.md](references/implementation-materials.md).
- Codex task association, active-duration accounting, minute-to-hour conversion, and completion-field writeback: [references/codex-time-accounting.md](references/codex-time-accounting.md).
- Batch discovery, stable snapshots, per-task continuation, worktree isolation, and final reporting: [references/batch-execution.md](references/batch-execution.md).
- Local Maven/pnpm dependency discovery, branch-safe reuse, and incremental-install fallback: [references/dependency-reuse.md](references/dependency-reuse.md).
- Mandatory per-node operation ledger, Git-grounded file inventory, batch attribution, and blocker reporting: [references/change-reporting.md](references/change-reporting.md).
- Start/submit/complete command split, one-click Bug repair, guarded branch-to-item matching, and release-comment traceability: [references/branch-submit-release-ledger.md](references/branch-submit-release-ledger.md).
- Before the first business-code write, use `scripts/route_lifecycle_intent.py` and `scripts/resolve_branch_base.py`; use `scripts/yunxiao_cli_delivery_ledger.py` for append-only events and `scripts/yunxiao_cli_submission_attempt.py` for multi-repository checkpoints. Before producing a new-format Yunxiao comment transaction, run `scripts/verify_lifecycle_suite.py` with the five absolute `SKILL.md` paths returned by official installation read-back; never hardcode another machine's Skill directory.
- Maven API artifact detection, guarded SNAPSHOT deployment, clean consumer re-resolution, and pipeline freshness gates: [references/api-artifact-publish.md](references/api-artifact-publish.md).
- YunxiaoPM handoff input, idempotency, and downstream rotation: [references/yunxiaopm-handoff.md](references/yunxiaopm-handoff.md).
- Test-task handoff without a test-pipeline gate, plus release-repair re-entry: [references/test-deployment-handoff.md](references/test-deployment-handoff.md).
- Requirement-level TestHub plan discovery, delivery-end case scope, lightweight verification, and requirement completion aggregation: [references/test-scope-aggregation.md](references/test-scope-aggregation.md).
- Authorization, live-change safety, evidence, and cross-skill handoff: [references/safety-handoff.md](references/safety-handoff.md).
- Independent release-task branch cleanup, retention, remote deletion, and current-machine local cleanup: [references/release-branch-cleanup.md](references/release-branch-cleanup.md).
- For every Yunxiao platform read/write not already covered by a specialized adapter, read the official CLI gateway, transaction-plan, idempotency, and performance rules: [references/yunxiao-cli-runtime.md](references/yunxiao-cli-runtime.md).
- When the user explicitly requests a fast lifecycle and the repository/deployment target is proven isolated, read and apply [references/rapid-flow.md](references/rapid-flow.md); never use it for real production.
- For `分配任务`, read the official CLI environment, hashed preflight/apply receipt, idempotency, field, relation, and read-back rules: [references/yunxiao-cli-allocation.md](references/yunxiao-cli-allocation.md); then read [references/requirement-snapshot.md](references/requirement-snapshot.md) and [references/allocation-technical-plan.md](references/allocation-technical-plan.md). Create the development requirement snapshot first and derive the technical plan from that exact snapshot.
- For `修复负责人是我的所有Bug`, read the official CLI adapter, credentials, frozen snapshot, status-write, and fallback rules: [references/yunxiao-cli-bug-batch.md](references/yunxiao-cli-bug-batch.md).
- Run bundled Python through the cross-platform launcher contract in [references/runtime-launcher.md](references/runtime-launcher.md).
- On every invocation, invoke `$development-brain` under the mandatory contract below. It owns its independent knowledge resources; pass only the current action, exact IDs, known scope and non-sensitive evidence pointers. Do not read or copy its installation files from this Skill.

The safeguards in this Skill are self-contained. If `git-submit-safety` is also installed, use it as an additional repository-specific guardrail.

## Own only the development boundary

Own these outcomes:

1. Accept a verified YunxiaoPM handoff whose requirement is already `待开发`.
2. Allocate one or more `【开发】` child tasks with developer, planned dates, and estimated hours. Copy and read back the source `【交付】` priority when present; when it is absent, leave the child priority unset (or accept a project-native default only when the platform applies it deterministically) and record a warning instead of blocking creation. Then move the source `【交付】` task from `待处理` to `已分配`.
3. On explicit or semantically clear start, resolve the correct verified base before the first business-code write. With one formal item, create/reuse its branch; with zero formal items, create a `tempdev/*` branch instance and local ledger identity. Never inherit an unrelated current branch. Perform the read-only dependency-reuse check and, when a formal owner item exists, write/read back an immutable `【研发启动】` event before moving its states. Starting a branch never downloads, installs, copies or rebuilds dependencies.
4. Let developers code independently after start. Before every commit/push/MR, compare the repository, branch instance, change summary and existing MR with the delivery ledger. A formal unique match submits automatically; a TEMPDEV may push only to its non-protected temporary branch for an explicitly requested test deployment and must remain `UNADOPTED`. Conflicting formal candidates pause only that repository and show both sides for one confirmation. When the verified change contains a Maven public API artifact, publish only the verified SNAPSHOT artifact to the configured snapshot repository, cleanly re-resolve it as a consumer, and record the receipt before a dependent test pipeline may run. This is package preparation, never a production deployment or release-repository publish.
5. In `完成开发`, classify validation before running it: an `新增` requirement with one exact formal TestHub plan and a configured current-end scope executes only that scope's real test cases for completion verification; every other case (优化、无计划新增、计划无法匹配或端侧范围未配置) runs the ordinary developer-side completion validation. Never mark a TestHub case without real execution evidence. Reuse an already pushed commit, merged MR, or trusted integration revision when it uniquely matches the task; create no duplicate commit or MR merely because completion is being run later or from another machine. If there are local changes, invoke the guarded `提交代码` node first. Normal mode requires an already integrated or newly merged revision; the explicitly enabled isolated rapid mode may use the verified remote source commit after a review-only merge rejection. Maintain an automatic incremental Codex task-segment index during development; completion queries that index by development-task ID, then performs only bounded asset/time-window metadata lookup and targeted deep reads. Never full-scan all conversations in the normal path and never ask the developer to select or confirm a conversation. Actual-effort writeback is best-effort: write and read it back only when start, duration, operator and precision are auditable; otherwise record `工时无可核验来源` without inventing values, and continue task closure, scope handoff and state read-back. After all completion actions and read-backs finish, retrospect the task-owned changes and their evidence-backed reasons.
6. Support `开始修复bug` and `完成修复bug` as separate traceable nodes. Keep `修复bug:<BUG-ID>` as the one-click orchestrator that executes start, repair/verify, guarded submit, and completion; it pauses for explicit confirmation on any branch-to-item mismatch. **Web** also deploys to test before `已修复`; **小程序** records `testPipeline=skipped` instead of a Flow deploy. Preserve `验证人/验证者` exactly as created by `YunxiaoQA`.
7. After each development task gets a trusted version, classify its requirement test mode immediately; never wait for sibling development tasks or their effort evidence. `优化` and `新增` without an exact formal TestHub plan normally write lightweight verification and do not create a formal test task. Do not take that shortcut when an existing same-scope formal `【测试】` task is found or the user explicitly requires QA handoff/evidence landing for this scope: create/reuse the test child with `testMode=qa-requested-exception`, do not invent a TestHub plan, and never advance the requirement directly to `测试完成`. Otherwise, once all lightweight scopes are closed, advance the requirement to `测试完成` through the real workflow, recording `oneos.lightweight-verification/v1`. `新增` with a plan creates/reuses one `【测试】` child for this delivery scope, associates it with the requirement, and assigns the unique `测试主管`. The first testable scope may move the requirement through `开发完成→待测试`; a later or post-hoc scope may continue when the requirement is already `待测试` or `测试中`, without rolling it back. Resolve the exact requirement plan and end-tagged directories with `yunxiao_cli_test_scope.py`; never title-match. Only real application/API/automation execution may update selected TestHub cases. Do not require an iteration for code delivery or scope-task creation; resolve it only for a formal test handoff.
8. Hand manual-case execution, retest, Bug closure, scope evidence, and requirement-level test completion to `YunxiaoQA`. A completed scope never by itself proves the whole requirement is test-complete.
9. Run `实现所有负责人是我的开发任务` as a stable batch that attempts every active assigned development task without letting one task-level blocker abort the remaining queue.
10. Run `修复负责人是我的所有Bug` as a stable consolidated batch: use `yunxiao_cli_bug_batch.py` through official `aliyun devops` CLI to freeze and update the current developer-actionable Bug list; use `yunxiao_cli_bug_delivery.py` to preflight/create Codeup branches, create/read/merge MRs, and start or attach to exactly one Flow test run. Edit, test, commit, and push locally only after the immutable plan passes; never perform Yunxiao platform writes through browser/DOM/Cookie fallback. Use the same frozen snapshot plus CLI-generated deployment evidence to move successfully deployed Bugs to `已修复` with exact read-back while preserving every Bug's existing `验证人/验证者`.
11. For every write-capable development, completion, and Bug node, emit the exact operations performed and the complete task-owned code-file inventory required by `references/change-reporting.md`; batch output must retain per-task or per-Bug attribution.
12. On `处理发布回流：发版任务=<ID>`, consume only a verified release/acceptance incident and QA-created Bug set, repair the frozen Bugs with the existing consolidated submission rules, perform one test handoff by end tag (**Web** one test deployment / **小程序** `testPipeline=skipped`), and hand the exact release repair batch back to `YunxiaoQA` for per-Bug retest.
13. On `清理分支：发版任务=<ID>`, require the release task to be `已完成` after product acceptance and verify the shared `oneos.product-acceptance/v1` evidence before cleaning eligible exact Codeup branches; `发布完成` alone must block cleanup. Safely clean matching branches on the current machine when possible, and report branches that other developers must clean on their own machines.
14. When a formal development task or Bug appears after TEMPDEV work, append `DELIVERY_ADOPTED` instead of renaming or rewriting Git history. A later development task aggregates existing independent Bug branches through `DEVELOPMENT_TASK_AGGREGATED`; every Bug keeps its own branch, commit, MR and retest identity. The aggregate records the exact branch set that release must consume.

This Skill does not impersonate the tester: **Web** developer-side automated tests and real-page checks prove implementation readiness only; **小程序** skips those checks by product rule. Formal case execution, current-run result recording, retest, Bug closure, and `待测试→测试中→测试完成` belong to `YunxiaoQA` after handoff. Do not publish production; hand release actions to `$yunxiao-release-operations`.

## Cross-Skill logical handoff

- Accept and emit only formal Skill names, exact requirement/delivery/development/test/release IDs, live states, formal `ASSOCIATED`/`TASK_SUB` relations, and necessary MR, commit, pipeline, deployment, evidence, or idempotency identifiers.
- Never discover, read, copy, or require another Skill's installation directory. This Skill owns its bundled resources; missing Yunxiao context must be resolved from the explicit handoff IDs and live services.
- Downstream selectors are `$YunxiaoQA` and `$yunxiao-release-operations`; product return is `$YunxiaoPM`. Never emit a legacy alias or a filesystem path as a command.

## Mandatory development-brain contract

`$development-brain` is a mandatory internal invocation for **every** `$yunxiao-development-delivery` command, including queries, plan mode, allocation, development, completion, single/Bug batch repair, release repair and branch cleanup. It is not a recommendation and cannot be skipped because this Skill already has a `开发复盘` section.

1. **Before selected work**: invoke its preflight after reading the command but before local code, Git, Yunxiao, Flow, Codeup or production writes. Supply only the command, exact work-item/Bug/release IDs when known, discovered repository/technology scope, and non-sensitive task/Git/test evidence pointers. Receive and retain its preflight receipt.
2. **During work**: apply only the receipt's scope-matching `confirmed` rule IDs. For each implementation/repair group, record the applied IDs or the evidence-backed reason that none applies. Candidate, pending, conflicting or expired knowledge cannot add a requirement, expand a diff, or justify any write. A confirmed-rule conflict blocks only the affected scope before a write; all ordinary gates in this Skill remain in force.
3. **After work**: after this Skill's required final Git-grounded `开发复盘` and verification evidence are available, invoke development-brain end review. It may add an evidence-complete `candidate`, or promote the same candidate only when development-brain's two-independent-task, score and safety gates all pass. Knowledge evolution may modify only the brain knowledge and release package; it must not change business code, task/Bug state, Git/MR, pipelines or production. A newly confirmed rule applies only to future work or a fresh preflight and cannot retroactively expand the completed task.

Failure handling is deterministic. A valid receipt with zero matching confirmed rules is `无匹配规则` and this Skill continues under its own gates. An unreadable/corrupt knowledge record or a matching confirmed-rule conflict is `安全阻塞`: diagnostic reads may continue, but no code, Git, Yunxiao, Flow, Codeup or production write may occur until the brain record is repaired or the conflict is explicitly resolved. An end-review knowledge write failure does not undo an already completed delivery; report `进化未落盘`, preserve its evidence-backed content and failure reason, and never claim it was retained or confirmed.

Every final response must include:

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

Command state contract:

| Command | Allowed lifecycle effect |
|---|---|
| `接收产品交棒` | Read and validate only; no task or state writes |
| `分配任务` | Create/reuse `【开发】`; write a requirement snapshot and snapshot-bound technical plan; `【交付】待处理→已分配`; requirement stays `待开发` |
| `开始开发` / batch development | Recheck snapshot freshness and deep-read only the task scope; refresh snapshot/plan when sources changed; then development child `待处理→处理中`, first child also moves `【交付】已分配→处理中` and requirement `待开发→开发中`; writes `【研发启动】` |
| Natural-language development with no formal item | Before the first business-code write, create one TEMPDEV delivery unit and one branch instance per repository from the verified integration base; no Yunxiao state write |
| `提交代码` | Does not move lifecycle state; commits/pushes/MR only after branch-to-item match or explicit reconfirmation; when needed, performs one guarded Maven API SNAPSHOT deployment and writes `【代码交付记录】` plus `【API包发布记录】` |
| `完成开发` | Complete the named development child after real validation; classify this delivery scope immediately. `优化` or an unplanned `新增` normally writes lightweight verification; an existing same-scope test task or explicit QA-handoff request switches only that scope to `qa-requested-exception`, prepares its test task, and forbids direct `测试完成`. A planned `新增` prepares only this scope's `【测试】` task and selected cases; it does not wait for siblings. Keep `【交付】=处理中` |
| `开始修复bug` / `完成修复bug` / `修复bug` | Writes start, delivery and completion comments; only completion changes the named Bug to `已修复`; preserve `验证人/验证者`; never move the requirement or `【交付】` |
| `处理发布回流` | Repair only QA-created Bugs formally tied to the release incident; one consolidated test deployment; no production or product-state writes |
| Branch cleanup | Change only eligible branches; never move a work item |

`【交付】` is the lifecycle container. This Skill must never perform `【交付】处理中→已完成`; that transition belongs to `YunxiaoPM` after production acceptance.

## Classify authority

- `audit`: inspect code assets, states, and logs only.
- `plan`: prepare tasks, branch/MR plan, or fix plan only.
- `apply`: create or modify exact named development tasks and formal relations.
- `fix`: edit code after root cause and scope are verified.
- `submit`: commit, push, open, or merge an MR only inside an explicitly invoked `提交代码`, `完成开发` for the exact development task, `完成修复bug:<BUG-ID>`, `修复bug:<BUG-ID>`, or the final consolidated-submission phase of `修复负责人是我的所有Bug`; always apply the guarded branch-to-item match. This authority may also deploy a verified Maven API **SNAPSHOT** artifact only through [references/api-artifact-publish.md](references/api-artifact-publish.md); it never publishes a release artifact or production package.
- `cleanup`: delete only exact eligible remote branches and safe matching local branches under an explicitly invoked `清理分支：发版任务=<ID>`.
- `document`: produce a development handoff or diagnosis report.

Creating a Bug does not authorize a fix. Generic diagnosis or code editing does not authorize submission. `开始开发` and `开始修复bug` never grant submission. Only an explicit `提交代码`, `完成开发`, `完成修复bug:<BUG-ID>`, or `修复bug:<BUG-ID>` can grant an exact-item submission after the guarded branch-to-item match. `完成开发` and the one-click Bug flow retain the applicable direct platform-permitted merge gate. The Bug batch grants submission only after the frozen queue's edit loop ends, limited to one consolidated commit/MR sequence per repository-and-branch group and one compatible test deployment for the batch. Only `清理分支：发版任务=<ID>` grants branch-deletion authority, limited to the exact release scope and the gates in `references/release-branch-cleanup.md`.

For an `UNADOPTED` TEMPDEV, a clear natural-language request such as “先上测试” grants one guarded commit/push to the already resolved non-protected TEMPDEV branch plus one compatible test deployment. It does not authorize merging to an integration/production branch, changing a formal work-item state, or placing the code in a production release. Every such action must append local `COMMIT_RECORDED` and `TEST_DEPLOYMENT_RECORDED` events so a later formal item can adopt the exact history.

`开发任务:任务=<ID> 输出执行方案` initially grants only `audit + plan`. Do not write Yunxiao, create branches, edit code, run state-changing test actions, or mark the goal complete while waiting. An explicit confirmation in the same Codex task upgrades the exact unchanged plan snapshot to `apply + fix`. `开始开发:任务=<ID>` and `开始修复bug:<BUG-ID>` grant only `audit + apply` for the named item: branch binding, start comment and state change, never code edits or submission. `开发任务:任务=<ID>` without the suffix grants `apply + fix` directly after the same internal analysis and gates, without displaying or waiting on the plan. `提交代码` grants `submit` only after the current-branch match passes or the developer explicitly confirms one displayed item. `完成开发` additionally grants `submit + direct merge attempt` for that task's verified repositories and actual integration branches. `完成修复bug:<BUG-ID>` grants guarded `submit + test-deployment coordination` only for the named Bug; `修复bug:<BUG-ID>` grants the full `apply + fix + submit + direct merge attempt + test-deployment coordination` one-click path. The Bug batch grants `apply + fix` per frozen Bug during its edit loop, then grants one consolidated `submit + direct merge attempt` phase per repository-and-branch group and exactly one batch test-deployment coordination action; it never invokes end-to-end single-Bug submission inside the loop. Review approval, CI result, and discussion resolution are not inspected, awaited, or used as Skill gates. Never execute author self-approval. In explicitly enabled isolated rapid mode, a merge rejected only by reviewer approval may continue with the verified remote source commit under `references/rapid-flow.md`; every other merge rejection blocks. These commands never grant production deployment, force push, administrator bypass, protection-rule disabling, unrelated refactoring, tester impersonation, or Bug closure.

## Execute

All Yunxiao Projex, Codeup, Flow, and AppStack discovery, state reads, relation reads, writes, pipeline actions, logs, and read-back must use the bundled official CLI adapters. Prefer the specialized allocation and Bug adapters; otherwise use `yunxiao_cli_gateway.py`. Never use a browser, screenshot/OCR, semantic DOM, Cookie, connector, or webpage-internal API for Yunxiao platform work, including as a fallback after CLI failure. Browser-based real-page verification is permitted only for the application being developed and never as Yunxiao evidence.

1. For development-task commands, resolve the exact project, requirement, numbered `【交付】` task, development task, repository, and real integration branch. For Bug commands, resolve the exact Bug and project first; Bug relations and repository fields are optional inputs.
2. Re-read the live requirement and `【交付】` task using the explicit YunxiaoPM identifiers. Accept only the contract in `references/yunxiaopm-handoff.md`; never search or deduplicate by title. For `分配任务`, perform these reads only through `yunxiao_cli_allocate_task.py` and official `aliyun devops` CLI.
3. For `分配任务`, first run `skill-run yunxiao_cli_allocate_task.py doctor` and `analyze --task ...`. Prefer the product handoff snapshot already left by YunxiaoPM in the requirement/delivery materials and project only this development task's scope into `<需求快照.md>`; if a legacy handoff has no product snapshot, reconstruct from authoritative referenced materials inside this Skill and mark it `历史补录`. Derive `<方案.md>` from that task snapshot. Translate the user parameters to `preflight --task ... --owner ... --plan-start ... --plan-finish ... --requirement-snapshot-file <需求快照.md> --technical-plan-file <方案.md> [--estimated-hours ...] [--development-task ...]`. Interpret `任务=<ID>` as the source `【交付】` task. Validate planned start ≤ planned finish and positive optional hours. Reuse may preserve the existing owner when the name is not unique; creation must block when the owner cannot resolve because the official CLI requires `assignedTo`.
4. Snapshot projection and legacy reconstruction are read-only and must not modify product assets, code, branches or Yunxiao. Then run the hashed preflight and `apply --preflight <回执>`. The adapter must re-preflight and reject drift, create/reuse `【开发】<需求标题>`, copy the source delivery priority when present, set developer/dates/hours while keeping `待处理`, create/read `PARENT→【交付】` and `ASSOCIATED→需求`, and aggregate-read every written field plus both managed blocks. A missing source priority is a warning, not a zero-write blocker; the adapter must not invent a business priority. Reused development tasks keep their existing priority. Only then may it move the source `【交付】` from `待处理 → 已分配`; `已分配|处理中` remains idempotent and `已完成` blocks. Never use browser/DOM/Cookie fallback.
5. Upsert managed `## 开发需求快照` and `## 技术实施方案` blocks in the development task description without overwriting business content. Both bind the formal requirement; the plan additionally contains the immutable snapshot hash. Neither block may contain Skill selectors or execution commands. Trust only the CLI apply receipt and final CLI read-back.
6. Do not require repository information at allocation or from the active conversation. During `开发任务`, analyze the requirement, affected page/interface/data, project configuration, existing code relations, accessible Codeup repositories, and current workspace to determine the applicable frontend/backend project automatically. Missing conversation-supplied repository addresses never block the node; stop only when the evidence itself remains contradictory after discovery and the modification target cannot be made safe.
7. For a direct `开发任务` initial start, require the requirement to be `待开发` and the source delivery task to be `已分配`. For a later sibling or post-hoc task, accept requirement=`开发中|开发完成|待测试|测试中` and delivery=`处理中` when the exact task scope and code target remain attributable; update only the current development task and never roll the requirement backward. A reusable first-start record is preferred but not required for off-machine or historical completion. This start gate does not apply to `完成开发`: that command follows step 20. Never change `已确认`/`设计完成` to `待开发` here.
8. For `开发任务`, accept the explicit work-item ID without requiring it to be a `【开发】` child. Prefer a direct requirement relation, then derive the source requirement and scope from the task parent, title, description, attachments, project/iteration context, existing code assets, and repository facts. Missing `TASK_SUB` or `ASSOCIATED` relations alone never block execution. Derive `新增` or `优化` from the resolved requirement/task title and infer `前端`、`后端` or `全栈`.
8.1. Read the allocation-written `## 开发需求快照` before the technical plan. Compare every authority listed under `来源与版本` with the live Yunxiao requirement and referenced PRD/prototype. If unchanged, deep-read only this task's chapters, pages and interaction states; do not reload the entire prototype or full PRD. If changed, rerun the read-only extraction, refresh the snapshot and regenerate its bound technical plan before start. If the snapshot exposes a plan omission, repair the plan first. A legacy task without a snapshot follows the same read-only generation path and reports compatibility recovery instead of being blocked merely for absence. Only an acceptance-critical rule conflict or unreadable required business material blocks the affected scope; missing optional hashes, visual aids or unrelated links are risks, not hard gates.
9. Select exactly one mode:
   - `开发任务:任务=<ID> 输出执行方案`: read and validate the allocated technical plan, then validate materials, relevant code and runtime facts. Return an `执行前方案复核`: reuse the stored plan, resolve code-side pending facts, and show only drift, gaps, risks, and the actual execution order; stop before every write. Keep the goal unfinished and wait for an explicit semantic confirmation such as `确认按方案执行 ONEOS-789`. On confirmation, re-read the stored-plan/requirement/material/code snapshot; if any execution-relevant fact changed, invalidate the review and return a revised review for confirmation instead of executing stale instructions.
   - `开发任务:任务=<ID>`: do not display a proposal or wait for confirmation. Validate and reuse the allocated technical plan, run live material/code gates, list the continuous execution tasks, and execute directly. Do not generate a duplicate generic plan; the legacy fallback remains only for a task without an allocation plan.
   A confirmation never overrides an unresolved mandatory gate or expands the confirmed scope.
10. Run the complete pre-write material gate in `references/implementation-materials.md`. For 优化, require a complete and implementable requirement description. For 新增, require a complete detailed requirement description plus at least one uniquely addressable canonical prototype, either local HTML or an accessible online entry. Compare local and online prototypes only when both exist; do not block merely because a duplicate copy is absent.
11. Only after material gates pass, use the developer's explicit or semantically clear implementation action as the authoritative start time. Persist the first real start timestamp once in a dedicated field when available; otherwise write an append-only ledger event. Never replace it with branch or commit time and never overwrite it on retry. When no formal item exists, keep the timestamp in the local TEMPDEV ledger until adoption; do not fabricate a Yunxiao comment target.
12. After the target project is automatically determined, inspect its real repository configuration and integration/default branches. Prefer frontend=`develop` and backend=`dev` when they exist, but absence of either name is not a gate; use the repository's verified actual integration branch and record the choice. Before any business-code write, run `resolve_branch_base.py` once per repository. Normal development/TEMPDEV uses the verified integration base; a test-discovered Bug uses the exact deployed test commit; a production hotfix uses the verified production baseline. An unverified test/production base may create only a provisional temporary repair with `retestRequired=true`, never a production-ready branch. Never create a branch from the current checkout merely because it is open.
13. Prefer `feature/<WORK-ITEM-ID>` or `fix/<BUG-ID>` for formal items and `tempdev/<DELIVERY-UNIT-ID>` for no-item work. One delivery unit may have several repository-specific branch instances. For every applicable repository, attempt to associate code assets with the requirement and development task. If either association is unsupported, unavailable, ambiguous, or fails read-back, record the result and continue; association success is not a branch, MR, merge, or completion gate. Defect fixes must still associate the Bug itself when Codeup supports that relation. A TEMPDEV is never a formal work-item relation and remains barred from production until `DELIVERY_ADOPTED` is appended and read back.
14. After the branch is created or reused, run the read-only discovery in `references/dependency-reuse.md` and record the chosen strategy in `【研发启动】`: direct reuse, local-store reuse, or incremental-install fallback with its reason. `开始开发` and `开始修复bug` stop after discovery and must not run Maven/npm/pnpm installation, copy another workspace's dependency directory, or build project artifacts. Then try native automation for `开发任务：待处理→处理中` and, for the first started child in the delivery tree, `【交付】任务：已分配→处理中` plus `产品需求：待开发→开发中`. Missing, disabled, or failed automation is not a gate: continue implementation and perform the same authorized state update directly or through the configured bridge, recording the actual method and result instead of claiming native automation passed. A later sibling starts only its own development task and does not repeat the parent or requirement transition.
15. Before the first local compilation, test, or real-page validation, apply the recorded dependency strategy from `references/dependency-reuse.md`. Reuse only when its fingerprint and runtime gate pass; otherwise run the smallest deterministic incremental install and record the actual fallback. Load `$apply-oneos-v2-frontend-guidelines` for frontend scope and `$alibaba-java-backend-guidelines` for Java backend scope. Inspect repository facts before editing and implement the validated material. Resolve the source `【交付】` end tag (`Web` / `小程序`; `PC` aliases to `Web`; mixed/missing tags block). **Web**: run proportionate automated and real-page verification against the final task-owned code version; do not treat source inspection as functional or visual verification. A launch failure in one worktree is a local verification-environment issue, not missing Yunxiao code association or iteration evidence. Use a clean equivalent workspace on the same verified branch when possible; if no equivalent final-version runtime can be made available, report `环境阻塞` and do not send the item to YunxiaoPM for relation repair. **小程序**: skip developer self-test cases, automated tests, and real-page verification; record the skip in the response.
16. For **Web** requirements, finish developer-side verification after implementation: compile/static checks, unit/integration tests, and proportionate real-page checks against the implemented version. Fix developer-discovered failures within the same scope. For **小程序**, skip those developer-side tests. Do not create a formal test run, write a tester result, close Bugs, or advance test-stage requirement states.
17. `开发任务` completes at verified implementation and task evidence. **Web** also requires developer-side validation. Formal QA completion is deliberately not a development-task gate because the `【测试】` task is created only in `完成开发`.
18. When `开发任务` passes, write a managed next-stage block containing `$yunxiao-development-delivery` and `完成开发:任务=<开发任务编号>`. Do not commit, push, create an MR, merge, or deploy during `开发任务`.
19. For a batch command, execute `references/batch-execution.md`: resolve the current account, freeze and display the active task snapshot, call this same single-task handler sequentially in isolated worktrees, record per-task active-duration segments and stops, and continue. A task-level stop never authorizes bypassing its gate.
20. For `完成开发`, inspect the matching `开发任务` execution evidence when present, but do not use missing or incomplete execution evidence, code-asset association, a start-state mismatch, or absence of this machine's start time as a gate for code validation, guarded submission, MR reuse/creation, merge attempt, task closure, or test-scope handoff. Accept a post-hoc task when an existing commit, merged MR, or integration revision uniquely proves its delivered code. Execute only genuinely missing material analysis, implementation or validation; do not recreate code, commits or MRs already delivered. Never fabricate a historical start time or effort: record `工时无可核验来源` and continue. **Web**: run a fresh developer-side completion validation against the final code and resolve every developer-discovered blocker before declaring verification passed. If the runtime is unavailable, preserve already proven code delivery and may create/reuse the scoped QA evidence landing, but mark validation as blocked and do not claim test readiness. **小程序**: skip that completion revalidation. Do not fabricate formal QA evidence.
21. After completion validation passes, fetch/pull first and stop only the conflicting repository on code conflicts. For a still-unsubmitted change, rerun scoped verification, then create/reuse one `oneos.delivery-submission-attempt/v1` and advance each repository from its last verified checkpoint. Commit messages and every ledger change summary must be Chinese. Publish any qualified Maven API SNAPSHOT artifact under [references/api-artifact-publish.md](references/api-artifact-publish.md), push, and create or reuse MRs for every applicable repository. A repository that already succeeded is never repeated because a later repository failed. For a post-hoc task, read and validate all existing commits/MRs/integration revisions and append `EXTERNAL_COMMIT_DISCOVERED` where needed; create nothing when trusted delivery already exists. Do not read, require, write, or infer an iteration/sprint at this MR node. Attempt to associate each MR with the requirement and development task; record `associated` or `skipped/failed` per relation and continue either way. A dependent test pipeline may run only after its API-package freshness gate passes; production pipelines and release repositories remain outside this Skill.
22. Do not inspect or wait for Codeup review approval, CI status, or discussion resolution. After MR creation, immediately attempt merge to the repository's verified actual integration branch. Never execute author self-approval. Normal mode requires the platform to accept the merge. After each successful merge, update and read back the same `【代码交付记录】` with repository, source/target branches, commit SHA, MR ID/URL, merged status and merged time; this read-back is mandatory before the development task may become `已完成`. In explicitly enabled isolated rapid mode, a rejection solely caused by reviewer approval or the author-self-review restriction is recorded once and the verified remote source commit becomes the delivery revision under `references/rapid-flow.md`; record the open-MR state instead. Never force push, use administrator bypass, or disable protection rules.
23. After every applicable repository has a verified delivery revision, attempt `references/codex-time-accounting.md`. When immutable first-start evidence, uniquely associated Codex duration, operator and precision are all auditable, calculate and write actual effort. When any input is unavailable, record the exact gap and `工时无可核验来源`; never substitute planned hours, wall-clock chat duration or another task's record.
24. When effort inputs are auditable, create or idempotently update one actual-effort record through `projex-create-effort-record` or `projex-update-effort-record`, and read it back. When they are not, skip only the effort write. In either branch, move the current development task to `已完成` after its own trusted delivery and validation gates pass, and read the task state back.
25. Keep the source `【交付】` task at `处理中`. Do not require sibling development tasks or their effort records before closing the current development task, classifying its test mode, creating/reusing its scoped test task, or handing it to QA. The first testable scope may move the requirement from `开发中` through `开发完成→待测试`; later scopes operate idempotently while it is already `待测试|测试中` and never roll state backward. Sibling completion is reported for aggregation only, not used as this scope's gate. The delivery task remains a cross-stage container and is closed only by `YunxiaoPM` after production acceptance.
26. Before creating or reusing a `【测试】` task, resolve the exact source `【交付】` task from the development task and requirement handoff, then read the current project's role membership and require exactly one user with role `测试主管`. Search for an existing valid test task by the same project, requirement, and delivery tree; never deduplicate by title alone. A role read failure, zero or multiple supervisors, multiple ambiguous test tasks, or an unresolved delivery task blocks only the test-handoff stage: do not create a new test task and do not move the requirement to `待测试`.
27. Create the new `【测试】` task directly under the source `【交付】` task, or make the single reusable task a child of that same delivery task. Require and read back both formal relations: `【测试】 TASK_SUB→【交付】` and `【测试】 ASSOCIATED→产品需求`. A reusable top-level task may be attached when unambiguous; a task already parented under a different delivery must not be detached or silently moved and blocks handoff. Explicitly set the owner to the resolved supervisor instead of accepting the creator, parent owner, delivery owner, developer, or platform default; replace any non-supervisor owner on a reusable task.
28. In the new or reused test task description, idempotently upsert a managed `## 开发交接` block with exactly two subsections: `### 测试建议` and `### 临时需求变更点`. Write the visible handoff as native Markdown with actual line breaks and list items; force `formatType=MARKDOWN`. Never write literal `<br/>`, HTML headings, `<pre>`, or raw JSON into the visible description. Machine data is limited to `oneos.test-scope/v1` in the hidden HTML-comment format. Derive concrete test suggestions from the requirement, implementation, changed interfaces/data/permissions, verification evidence, scoped Bugs, MRs, environment prerequisites, boundary paths, and regression surface; never use a content-free phrase such as “全面测试”. Record only explicitly confirmed deviations from the original requirement as temporary changes, including the changed behavior, original behavior, reason, confirmation evidence, impact, and follow-up when known. If none exists, write `- 无（本次开发未发生已确认的临时需求变更）`. Preserve all human-authored description outside the managed block, and replace rather than duplicate the block on retry. An unconfirmed candidate that affects acceptance blocks test handoff instead of being recorded as a confirmed change.
29. Read back the test task's `TASK_SUB` parent ID, `ASSOCIATED` requirement ID, owner user ID, both managed headings, and their actual content. Parent ID must equal the source delivery task ID and requirement ID must equal the source product requirement ID. Any relation, owner, or description write/read-back mismatch blocks test handoff.
30. After the current development task has completed and the test task/relations/owner/description have been prepared, perform the separate requirement transition toward `待测试` when the live workflow still requires it and read it back. If the requirement is already `待测试` or `测试中`, treat that state as an idempotent continuation and do not roll it back. Neither an iteration nor test-pipeline evidence is a completion or test-start gate. Emit the formal handoff with the current scope, followed by `$YunxiaoQA` and `开始测试：测试任务=<测试任务编号>；需求=<需求编号>`; do not fabricate a test result.
31. Do not discover, start, attach, or write `oneos.test-deployment/v1` for ordinary development completion. Web test-pipeline execution is not an ordinary development-completion action; 小程序 has no cloud test-pipeline action.
32.1. After every completion action and required read-back has finished, retrospect only the current development task's final Git/MR file inventory. Output `开发复盘` with `修改内容` and `修改原因`; derive reasons from the requirement, Bug, task plan, commit/MR and actual code evidence. Do not invent a reason, include unrelated files, or perform a new write because of the retrospective.
33. For `修复bug:<BUG-ID>`, resolve the exact Bug and require a developer-actionable non-terminal state; the Bug owner may be any user and must not be reassigned implicitly. Read formal association items, requirement, development-task, failed-case, and repository relations when present, but allow zero association items and no repository metadata. Resolve the target codebase from the active workspace, Bug description, reproduction path, page URL or interface, runtime evidence, and current conversation. Stop before code writes only when reproduction input, repair scope, or target environment is missing, or conflicting evidence makes the modification target unsafe. The developer must not read the creator merely to derive a verifier and must never change `验证人/验证者`.
34. Select the repair branch independently for every affected repository. When the Bug has association items, follow their formal relations to the underlying requirement, then inspect that requirement and its development tasks for a remotely existing, writable, safely synchronizable development branch formally associated with the same repository. Reuse it only when exactly one valid branch is resolved. A missing, multiple, non-writable, non-synchronizable, or conflicting associated development branch is a zero-write blocker; never create `fix/<BUG-ID>` for an associated Bug. Only a Bug with proven zero formal association items may create or reuse its own `fix/<BUG-ID>` from the repository's verified actual integration branch. Never choose a branch by title/name resemblance alone. Associate the selected branch and later MR with the Bug itself, and retain independently proven requirement/development-task/failed-case relations without fabricating missing ones.
35. Reproduce the Bug, implement the smallest in-scope fix, and verify the failing path, boundaries, and adjacent paths. Keep the same single-Bug node active while fetching latest code, rerunning scoped verification, committing, pushing, opening or reusing the MR, and immediately attempting a platform-permitted merge to the verified integration branch. Do not inspect or wait for review approval, CI status, or discussion resolution, and never execute author self-approval. Code conflicts, a wrong target branch, a technically non-mergeable MR, or a platform rejection still stop that Bug without bypassing protection.
36. Coordinate or verify one test deployment for the single Bug without modifying production pipelines. Only after the deployed test version is proven, set the Bug to `已修复` and read back its status before handing it to `YunxiaoQA`. Do not write or gate on `验证人/验证者`; that field is owned by `YunxiaoQA` when the Bug is created. Never close it or write a passing retest.
37. For `修复负责人是我的所有Bug`, first run `skill-run yunxiao_cli_bug_batch.py doctor --require-auth`, then `snapshot --space-id <精确项目ID>...`. Resolve each Bug's exact repository and branch by step 34, group by exact repository plus target branch, and create `oneos.yunxiao-cli-bug-delivery-plan/v1`. Run `skill-run yunxiao_cli_bug_delivery.py preflight --plan <计划JSON>` before code writes. The preflight must prove Codeup IDs/permissions/branches and discover the pre-created test Flow by exact source repository, target branch, deployment target and logical test environment; a supplied pipeline ID or pipeline name is only a narrowing hint and must pass the same checks. Infer manual versus automatic execution from the existing trigger configuration. `manual-cli` is forbidden when an automatic target-branch trigger exists; `auto-after-merge` requires exactly one relevant trigger event. Zero or multiple existing matches block without creating or modifying Flow. Do not use browser Cookie or DOM writes when any CLI, authentication, project, Codeup, or Flow gate fails.
38. Run `ensure-branches --preflight <回执>` so Codeup branch creation/reuse and read-back occur through CLI. Then loop through processable Bugs: use `yunxiao_cli_bug_batch.py set-status` when the live state must enter the real in-progress state, edit and validate locally, and record per-Bug diff boundaries. Do not commit, push, create an MR, merge, or deploy inside the loop. Group workspaces by exact repository plus selected target branch and never mix unrelated pre-existing changes.
39. After the last processable Bug passes local validation, rerun combined checks and reconcile each group. Create at most one local commit and one native `git push` per group, then write the group-to-remote-commit map. Run `ensure-mrs --branches <回执> --commit-map <映射>` and `merge-mrs --mrs <回执>` so Codeup MR creation, Bug association, merge, and `mergedRevision` read-back all use CLI. Finally run `start-test-pipeline --merges <回执>` exactly once: manual mode starts one Flow run; automatic mode starts none and attaches only to the unique post-baseline run containing every merged revision. Any failed group, zero automatic run, or multiple matching runs blocks status completion and never causes a compensating second deployment.
40. Run `check-test-pipeline --run <回执>` until terminal. Only a successful Flow run whose source proves every merged revision may generate `oneos.test-deployment/v1`. Pass that file to `yunxiao_cli_bug_batch.py set-status --snapshot <快照文件> --target 已修复 --deployment-evidence <证据文件> --serial <BUG-ID>...`. The adapter updates only `status`, then exactly re-reads serial, status, owner, and verifier. A per-Bug status failure blocks only that Bug; never repeat submission or test deployment. Preserve per-Bug operations and attribution although commit/MR/deployment evidence is shared.
41. For `处理发布回流：发版任务=<ID>`, execute `references/test-deployment-handoff.md`: verify the release incident and rollback/acceptance evidence, require the QA-created Bug set, reuse the consolidated Bug repair path, deploy once to test, and emit `验证发布回流`; never start production or skip QA retest.
42. Before the final response for `分配任务`, `开发任务`, batch development, `完成开发`, single-Bug repair, batch Bug repair, or release repair, execute `references/change-reporting.md`. Record repository baselines before writes, derive file lists from live Git evidence, distinguish planned from actual changes, and emit both `实际执行操作` and `实际代码变更` even when blocked. Do not report a node or batch complete when these sections are missing.
43. For `清理分支：发版任务=<ID>`, execute `references/release-branch-cleanup.md`. Re-read the release task, require state=`已完成`, validate the product-acceptance evidence and immutable production anchor, derive candidates from trusted task/Bug/MR relations, apply retention and per-branch safety gates, delete eligible exact remote branches with read-back, and perform only safe current-machine local cleanup. Never change the release, requirement, task, or Bug state. Treat already-absent branches as idempotent success and report other developers' local branches as requiring the same command on their machines.

## Non-negotiable gates

- Labels are module metadata, never development identity.
- Use the `【开发】` prefix when creating development children and for batch discovery, but do not require that prefix or a child-task type when an explicit `开发任务:任务=<ID>` is invoked.
- Every command has a precondition gate. On failure, perform no state-changing action and return the failed check, live value, expected value, impact, and exact remediation or next command.
- Batch execution may continue past a failed task but may not continue that task past its failed gate.
- Bug batch execution may continue past a failed Bug but may not continue that Bug past its failed gate.
- Freeze the batch task list before implementation. Do not silently add tasks assigned during the run.
- A clear development intent with no unique formal item is not a dead gate: create a local TEMPDEV delivery unit and safe branch before the first business-code write. It may be pushed to a non-protected temporary branch and deployed to test only when that test action is explicitly requested. It may not enter a production merge plan until adopted by one formal task, Bug or approved technical-improvement item.
- A later formal item adopts TEMPDEV by append-only evidence; never rename the old branch, rewrite commit history or duplicate commits merely to make the identifier look correct. Multiple TEMPDEV/independent Bug branches may map to one development task and remain separate release inputs.
- New `oneos.delivery-ledger/v1` comments may be written only after all five lifecycle Skills are officially read back at suite version `10.0.0`. Before that feature gate opens, read both formats, keep new TEMPDEV events locally, and do not mix new comments into Yunxiao; this is never a code-development dead gate.
- Use an isolated worktree or equivalent workspace for every batch task; never mix unsubmitted changes from different tasks.
- Do not copy, bind-mount, or directly share `node_modules`, `target`, `dist`, or other branch build outputs across worktrees. Resolve Maven and pnpm cache directories on the current machine at runtime; never assume a default user-home path. Dependency downloads are allowed only as the documented incremental-install fallback before real local validation, never as a branch-creation side effect.
- For Bug batches, group worktrees by exact repository plus selected target branch. Multiple frozen Bugs may intentionally share one group only when their diff boundaries remain auditable; never mix a development task, an unrelated Bug, or pre-existing user changes into that workspace.
- Do not mark the batch goal complete while any snapshot task remains unimplemented or blocked.
- In `分配任务`, `任务=<ID>` always identifies the source `【交付】` task, never the child development task.
- `分配任务` must write the requirement snapshot before its snapshot-bound technical plan. The absence of a snapshot on a legacy task is recoverable at `开始开发`; do not turn it into an unconditional lifecycle blocker.
- `分配任务` must use `yunxiao_cli_allocate_task.py` through official `aliyun devops` CLI for every Yunxiao read and write. Missing CLI/plugin/PAT/organization ID, a changed preflight fingerprint, or an ambiguous create-time owner is a zero-write blocker; never fall back to browser/DOM/Cookie operations or expose credentials.
- Never reassign the `【交付】` task from its officially read-back current owner or overwrite its planned dates or estimated hours. This Skill owns only `待处理 → 已分配 → 处理中`; `处理中→已完成` belongs to post-release product acceptance in `YunxiaoPM`.
- If a referenced `【交付】` is already `已完成`, do not create/reopen development or test children and do not roll any state back. A new post-acceptance change must return to `YunxiaoPM` for a new requirement/delivery lifecycle.
- Allocation must attempt both `TASK_SUB→【交付】` and `ASSOCIATED→需求`, but missing task/code/MR association results are traceability warnings, never a `开发任务`, code-delivery, or `完成开发` gate; derive the source scope from task and project evidence and report the missing traceability.
- The managed next-stage description block is idempotent and must not overwrite human-authored description content.
- Derive type, scope, target project, repository, and actual integration branch automatically from requirement, task, project, Codeup, runtime, and workspace evidence. Never require repository addresses from the conversation.
- `开发任务` accepts only `任务=<开发任务编号>` plus the optional literal suffix `输出执行方案`. Do not require or encourage `类型=`、`仓库=`、`前端仓库=`、`后端仓库=`、`范围=` or `基线=`.
- Plan mode is read-only until explicit same-task confirmation. Keep the goal unfinished while waiting; do not mark it complete or blocked merely because confirmation is pending.
- Direct mode skips plan presentation and confirmation only. It never skips requirement/material, state, repository, implementation, or verification gates.
- Re-read plan inputs before executing a confirmed plan. Any execution-relevant change invalidates the confirmation and requires a revised plan.
- Plan mode must label its operation and code sections as planned and unexecuted. After confirmation, replace them with actual evidence; never present a proposal as completed work.
- Every write-capable node must report `实际执行操作` and `实际代码变更`. Use Git status/diff/commit/MR evidence and include every task-owned added, modified, deleted, or renamed file with behavior, reason, line counts, and verification.
- Record the pre-write repository baseline and exclude unrelated pre-existing dirty files. Never claim another task's or the user's existing changes.
- Batch development and batch Bug repair must repeat the operation ledger and code inventory for every item. Aggregate counts never replace per-item details.
- A blocked node must still report completed operations, current task-owned differences, unexecuted actions, retained worktree/branch, and continuation condition.
- If no code changed, write `代码变更：无` with an evidence-backed reason. Do not claim a code implementation or code-defect repair complete without code changes unless the proven resolution is configuration, data, environment, or genuinely no-code.
- Prefer frontend=`develop` and backend=`dev`, but their absence is not a gate; use the repository's verified actual integration branch.
- Missing or failed branch-association automation is not a gate. Record whether state changes were native, bridged, or direct.
- An optimization requirement with empty, unreadable, placeholder, or ambiguous description must stop with specific missing information.
- A new requirement requires a complete detailed requirement document plus at least one uniquely addressable canonical prototype (local HTML attachment or accessible online entry). Attachment count=0 or lack of a duplicate local/online copy is not itself a blocker when those two materials are complete and traceable. Compare local and online prototypes only when both are available; conflicting copies or an unreadable business-material reference must stop the affected scope with evidence.
- A **Web** development task cannot complete without proportionate developer-side automated and real-page verification against the implemented version; a **小程序** development task records the skip instead. This evidence (or skip note) is not a formal QA plan, case execution, report, or acceptance result.
- `完成开发`: **Web** must run a fresh developer-side completion validation rather than reusing the first validation record; **小程序** skips that revalidation and records the skip.
- Developer-discovered failures remain inside the development scope; formal Bug creation, retest, closure, and test evidence follow `YunxiaoQA` after test handoff.
- Creating or reusing `【测试】` and moving the requirement `开发完成 → 待测试` are two separate verified actions. The test task must be a formal `TASK_SUB` child of the exact source `【交付】` task and `ASSOCIATED` with the source requirement. These two relation IDs, exactly one project `测试主管`, owner-role equality, and the managed description are mandatory read-back gates.
- Never require an iteration/sprint, test pipeline, or `oneos.test-deployment/v1` for commit, push, MR creation/merge, actual-effort writeback, development-task completion, test-task creation, or `开发完成 → 待测试`.
- **Web** test pipelines are pre-created platform configuration and are relevant only to Bug test deployment or another explicitly authorized test-pipeline node. Resolve them by exact Codeup source, target branch, deployment target and logical test environment; the pipeline name is only a hint and need not contain `test/测试`. Never create, copy, update, rename, or delete a Flow pipeline or service connection from this Skill; zero or multiple matches block only the pipeline-dependent node. **小程序** does not discover or start test pipelines.
- Never leave a newly created test task at project top level. A reusable top-level test task may be attached only when its requirement and delivery are unambiguous; never detach or silently reparent a task from another delivery tree.
- The managed `## 开发交接` block is idempotent and must preserve human-authored description outside it. Never fabricate temporary requirement changes; an acceptance-affecting change without explicit confirmation blocks handoff.
- Development may mark a Bug `已修复` but may not close it or write a passing retest result; only `YunxiaoQA` may do so from retest evidence.
- Planned dates and estimated hours are scheduling data; they do not prove real development start.
- YunxiaoPM is the only product-stage entry. This Skill must not accept `已确认` or `设计完成` as development intake.
- A YunxiaoPM handoff intentionally has no `【开发】` or `【测试】` task. Their absence is not a handoff failure.
- Never create a second `【交付】` task or recreate missing analysis/design tasks during development intake.
- A fast-track or number-push handoff may legitimately have no analysis task or no design task.
- A placeholder `【交付】` description is an explicit product risk, not proof that design is complete.
- A commit does not prove development completion. Review approval, CI status, and discussion resolution are intentionally not merge gates. An MR may be merged only to the verified actual integration branch when it is conflict-free, technically mergeable, and accepted by Codeup under current permissions and protection settings.
- Requirement and development-task association for branches and MRs is best-effort. Attempt it for every applicable repository, record the outcome, and continue when unsupported or unsuccessful.
- Never execute author self-approval. The Skill may attempt a merge without waiting for optional review, but Codeup protection and permissions remain authoritative.
- A requirement involving one repository must not wait for an explicitly non-applicable repository; a multi-repository requirement must not finish early.
- `已修复` means ready for retest, not closed.
- The one-click single-Bug command is exactly `修复bug:<BUG-ID>` after `$yunxiao-development-delivery`; it orchestrates `开始修复bug`、修复与验证、`提交代码` and `完成修复bug`. The split commands remain available for developer-led coding; legacy `接收Bug` is retired and `Bug修复完成` is renamed to `完成修复bug`.
- The canonical Bug batch command is `修复负责人是我的所有Bug` after `$yunxiao-development-delivery`. Accept close semantic equivalents, but always freeze and display the list; do not invoke the end-to-end single-Bug submit/deploy handler inside the loop.
- A single-Bug command may repair a Bug owned by any user. Never reassign it implicitly; preserve and report the live owner.
- A Bug may have zero association items and no repository information. Missing repository information is not a repair gate. With one or more formal association items, follow them to the requirement and reuse exactly one verified, writable and synchronizable development branch; a missing, multiple or unsafe branch blocks with zero writes. Only a proven association-free Bug may create or reuse `fix/<BUG-ID>` from the verified integration branch. Always associate selected branch/MR assets with the Bug itself and stop if the modification target cannot be safely determined.
- Development must never set, clear, replace, or gate completion on a Bug's `验证人/验证者`. `YunxiaoQA` sets that field to the current test user when the Bug is created; development preserves it through single and batch repair.
- Bug batches must perform zero commits, pushes, MRs, merges, or deployments during the per-Bug edit loop. Submit at most once per repository-and-branch group after the loop; **Web** then triggers exactly one compatible test deployment for the batch, **小程序** records `testPipeline=skipped` instead.
- The Bug batch must use the bundled official CLI adapters for current-user resolution, Bug snapshot/status/read-back, Codeup repository/branch/MR/merge operations, and Flow run/evidence operations. Missing CLI/plugin/PAT/organization-or-endpoint/project IDs, ambiguous Codeup identity, unsafe trigger configuration, or pipeline/revision mismatch is a global preflight blocker. Never print the PAT or other secrets, pass them as command arguments, store them in plans/receipts/Skill files, or silently fall back to browser/Cookie writes.
- No development or Bug command requires conversation-supplied repository addresses; determine target projects automatically from the work item and code/runtime evidence.
- `清理分支` requires one exact `发版任务` ID, live state=`已完成`, and valid passing `oneos.product-acceptance/v1` evidence consistent across the release task, in-scope requirements, and source delivery tasks. State=`发布完成` means product acceptance is still pending and must produce zero deletions. Release failure, failed/missing/inconsistent acceptance evidence, rollback/uncertainty, missing immutable production anchor, ambiguous scope, insufficient relation/MR proof, or unmet retention keeps the affected branch and reports why.
- Branch names are discovery hints, never deletion proof. Never delete default, protected, integration, or long-lived branches; never use wildcard deletion, force push, `git branch -D`, administrator bypass, or protection-rule changes.
- Remote cleanup and local cleanup are separate. This Skill may clean current Codeup remotes and safe local branches only on the machine where it runs; it cannot delete branches on another developer's computer.
- Do not set a Bug to `已修复` without code verification, MR evidence, and proof that the test environment contains the fixed version. Do not close a Bug; retest and closure belong to `YunxiaoQA`.
- Actual-effort evidence is independent from code delivery and lifecycle closure. Write and read an effort record only when its source data are auditable; otherwise record `工时无可核验来源`, leave the effort record absent, and continue the current task's verified closure and test handoff.
- Use the latest applicable MR `merged_at` as the precise completion timestamp in normal mode, or the trusted remote delivery-commit time in isolated rapid mode; do not use the command execution time, first commit time, first MR merge time, or the date-only work range as a substitute.
- Automatically maintain `oneos.codex-task-segment/v1` whenever a unique development-task context is established, even when the user did not use a standard command. At completion, query by development-task ID, then use formal Bug/MR/commit/branch relations and the bounded start-to-completion metadata window to repair only missing links; deep-read only metadata hits and never full-scan all conversations in the normal path.
- Count only Codex tasks or per-item segments with a unique, auditable relation to the development task. Deduplicate by Codex task ID plus segment ID and never assign an unsegmented multi-task conversation in full to more than one development task. Conflicting or indivisible shared segments become `未归属`; do not ask the developer to select, classify or confirm them.
- Sum raw active elapsed seconds first, then round once to minutes. Convert with `计算工时 = 总分钟数 ÷ 60`, using half-up rounding to two decimals as the source value. Write that value to the effort record; if Yunxiao deterministically normalizes it to the project's configured precision (for example `0.28 → 0.3`), preserve both the calculated value and the read-back value in the work description and accept only the read-back value as the platform record. Preserve the integer minutes and unrounded calculation in the audit evidence.
- If active elapsed duration, association evidence, effort-record precision, work-date range, precise timestamp description, operator, or read-back cannot be verified, skip the effort write and report the missing evidence. Never substitute first-message-to-last-message wall-clock duration or planned hours, and never use the gap to block unrelated code, task-state or test-handoff actions.
- Every generated next-stage command must start with an explicit `$<skill-name>` selector.
- Never modify production pipelines from this skill.
- Maven API artifact automation may publish only a verified `-SNAPSHOT` coordinate to the configured snapshot repository. Missing/invalid snapshot repository configuration, a release coordinate, an unreadable consumer re-resolution, duplicate uncertain publication, or an unproven pipeline refresh policy blocks the API-package or pipeline-dependent node; it never falls back to a release repository, production package, or blind retry.
- A missing CLI/plugin/PAT/organization-or-endpoint capability is a zero-write blocker. It never authorizes visual or browser fallback.

## Return

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