yunxiao-development-delivery

Yunxiao Development Delivery

Automatic first update of each day (mandatory, before other actions)

When this Skill is first triggered on each local calendar day, execute first:

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

updated: the five Yunxiao lifecycle Skills have been updated uniformly; you must re-read this SKILL.md in full and all references needed for this session before continuing, and then call development-brain to perform the development pre-check.
skipped-today: the update has already succeeded today; continue directly.
in-progress: another related Skill is performing the same update; continue directly and do not concurrently repeat the update.
failed / unavailable / cooldown: give only one brief prompt and continue the current task; an update failure must not block development work.
The shared update scope is fixed to YunxiaoPM、yunxiao-development-delivery、development-brain、YunxiaoQA、yunxiao-release-operations user-level global installation; this must not be used to modify project-level Skills, business repositories, Yunxiao data, pipelines, or the production environment. Do not manually forge or pre-write the daily success status.

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

Load the required references

完成开发 uses a non-optional product handoff gate. Missing, invalid, incompatible, unreadable or mismatched product records must stop all completion-flow writes, including test-task creation/update. Do not downgrade to warnings, status-only completion, an optional-effort failure, or a user-confirmation shortcut. Keep existing business records intact; obtain corrected product evidence and run a new preflight. Direct commands, implicit completion, historical recovery and resuming an old preflight all use the same gate.
Before a formal development start or completion, read version-bound handoff gates. Read the current scoped contract and required materials, return a reviewed understanding receipt and explicit engineering decisions; never infer product decisions. Immediately before formal start/resume or the first business-code write, run yunxiao_cli_handoff.py verify --bundle <bundle.json> --task-id <exact internal development ID>: it reads the live requirement and delivery through official CLI and checks actual material bytes. An old local-only PASS or an earlier preflight never substitutes for this fresh check. At completion provide evidence.handoffEvidence to the dedicated executor; it checks live product manifests, content hashes, task/version binding and writes the receipt into the development task. Historical recovery may gather evidence but cannot waive this formal gate. This scoped gate overrides older optional-hash / missing-evidence compatibility wording below; no need to load unrelated full PRDs or this PM's local subagents.

Read each selected file completely before acting:

Development task, Codeup, stage-task and OneOS controls: references/controls.md.
Short Chinese commands and defect-fix workflow: references/commands.md.
For implicit invocation, natural-language normalization, unique task selection, and development-versus-test disambiguation, read references/semantic-routing.md completely before selecting a command.
开发任务:任务=<ID> direct/plan modes, new/optimization material gates, prototype comparison, and implementation completion: references/implementation-materials.md.
Codex task association, active-duration accounting, minute-to-hour conversion, and completion-field writeback: references/codex-time-accounting.md.
Batch discovery, stable snapshots, per-task continuation, worktree isolation, and final reporting: references/batch-execution.md.
Local Maven/pnpm dependency discovery, branch-safe reuse, and incremental-install fallback: references/dependency-reuse.md.
Mandatory per-node operation ledger, Git-grounded file inventory, batch attribution, and blocker reporting: 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.
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, scripts/yunxiao_cli_submission_attempt.py for multi-repository checkpoints, and scripts/classify_completion_readiness.py after a successful explicit submission to decide automatic completion, one confirmation, or stop. Development ledger writes and completion use this Skill's bundled adapters and validate the actual handoff schemas and evidence; never require installation paths or matching installed versions of the other lifecycle Skills.
Maven API artifact detection, guarded SNAPSHOT deployment, clean consumer re-resolution, and pipeline freshness gates: references/api-artifact-publish.md.
YunxiaoPM handoff input, idempotency, and downstream rotation: references/yunxiaopm-handoff.md.
Test-task handoff without a test-pipeline gate, plus release-repair re-entry: 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.
Post-submit completion assessment and automatic/confirm/stop/test-delivery decisions: references/completion-readiness.md.
Historical tasks whose branches, commits or MRs predate the task or lack task relations: references/historical-code-recovery.md. Recover the exact mapping from official Codeup evidence; do not treat a missing live source branch as missing delivery when a merged MR still proves it, and do not adopt all same-module changes by author or date.
Authorization, live-change safety, evidence, and cross-skill handoff: references/safety-handoff.md.
Independent release-task branch cleanup, retention, remote deletion, and current-machine local cleanup: 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.
When the user explicitly requests a fast lifecycle and the repository/deployment target is proven isolated, read and apply 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; then read references/requirement-snapshot.md and 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.
For the QA special repair channel, validate and accept oneos.test-bug-repair-request/v1 with scripts/yunxiao_cli_bug_repair_channel.py, then reuse the ordinary Bug repair/merge gates.
Run bundled Python through the cross-platform launcher contract in 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:

Accept a verified YunxiaoPM handoff whose requirement is already 待开发.
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 已分配.
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.
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.
In 完成开发, classify validation before running it. Read the exact requirement's TestHub plan directly through yunxiao_testhub_read_api.py. The default and fixed request is official ListTestPlan with Content-Type: application/json; never first probe the known-broken test-hub-list-test-plan CLI, query its plugin version, or upgrade/retry that plugin as a prerequisite. Use environment PAT and no redirects. Successful reads record available-json-api; actual retryable service/transport failures record unavailable-json-api/plan-read-skipped with the real JSON error and trace IDs, without a plugin upgrade. Unsupported Region/custom endpoints, authentication, permission and malformed/cross-project responses block. When the read succeeds but the requirement has no associated formal plan, explicitly skip formal plan/case validation. When an exact formal plan has a configured current-end scope, read its real result entries and freeze the deduplicated directory and testcase IDs into the test handoff; do not update TestHub results. Every scope still runs the applicable developer-side completion validation. Only YunxiaoQA may execute the frozen formal cases and write their results from real test 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. After code delivery and validation evidence are frozen, all lifecycle writes must use yunxiao_cli_complete_development.py: prepare the test task first, close the development task second, advance the requirement third, then run final official read-backs. After all completion actions and read-backs finish, retrospect the task-owned changes and their evidence-backed reasons.
Support 开始修复bug and 完成修复bug as separate traceable nodes. 修复bug:<BUG-ID> executes start, repair/verify, guarded submit, MR creation/reuse, merge and official read-back. Both Web and Mini Program require verified development checks and an actually merged MR before 已修复. Record 待部署、待交付测试; do not discover, start or wait for Flow in repair completion. Preserve 验证人/验证者.
Support 处理测试修复请求：缺陷=<BUG-ID> as a special QA-to-development entry. It must read and validate the latest structured QA request, append the development acceptance comment, then continue the existing 修复bug:<BUG-ID> action without asking QA to restate the evidence. It may finish only as 已修复 with merge/validation evidence or 暂不修复 with reason, approver, approval evidence and next action; the QA role never writes either status.
After each development task gets a trusted version, classify its requirement test mode immediately; never wait for sibling development tasks or their effort evidence. Every non-cancelled 【开发】 task must create or reuse exactly one corresponding 【测试】 child under the same delivery, associate it with the same requirement, record its developmentTaskId, and assign the unique 测试主管. A formal TestHub plan with nonempty current-end cases selects testMode=formal-plan; a successful plan read with no associated plan, no end-tagged directory or an empty directory skips formal TestHub validation and uses testMode=mandatory-test-task. An actual retryable JSON service/transport failure also uses mandatory-test-task, recorded as plan-read-skipped, never as confirmed absence. All of these modes still require QA completion. lightweight-verification is retired and must never advance a requirement or satisfy release readiness. 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, end-tagged directories and selected testcase IDs with yunxiao_cli_test_scope.py; never title-match. Only YunxiaoQA with real application/API/automation evidence 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.
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.
Run 实现所有负责人是我的开发任务 as a stable batch that attempts every active assigned development task without letting one task-level blocker abort the remaining queue.
Run 修复负责人是我的所有Bug as a frozen batch using official CLI. Preflight Codeup repositories and branches, verify locally, commit/push by group, create/reuse and merge MRs, then verify merge and development evidence for each Bug. Use set-status --merge-evidence ... --validation-evidence ... to write and read back 已修复 plus a pending-deployment/test-handoff record. No Flow gate or browser/DOM/Cookie write fallback.
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.
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 / Mini Program testPipeline=skipped), and hand the exact release repair batch back to YunxiaoQA for per-Bug retest.
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.
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; Mini Program 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.

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.
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.
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:

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

Command state contract:

Command	Allowed lifecycle effect
`分配任务`	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
`提交代码`	Commits/pushes/MR only after branch-to-item match or explicit reconfirmation; after remote read-back, classifies completion readiness. Confirmed completion continues automatically, likely completion asks once, and incomplete work stops without lifecycle changes. When needed, performs one guarded Maven API SNAPSHOT deployment and writes `【代码交付记录】` plus `【API包发布记录】`
`完成开发`	Complete the named development child after real validation. Freeze the exact scope and run `yunxiao_cli_complete_development.py` so the unique `【测试】` task, owner, relations and managed description are verified before the development child can become `已完成`; then move the requirement only to `待测试` or retain `测试中`. A formal plan uses its selected scope. A successful read with no associated plan skips formal TestHub validation and uses `mandatory-test-task`. Read plans directly with the official JSON adapter and fixed Content-Type; never probe the broken plan-list CLI or upgrade its plugin first. Actual retryable JSON service/transport failures skip that stage with visible diagnostics while retaining the mandatory test task. Keep `【交付】=处理中`
`开始修复bug` / `完成修复bug` / `修复bug`	Writes start, delivery and completion comments; only completion changes the named Bug to `已修复`; preserve `验证人/验证者`; never move the requirement or `【交付】`
`处理测试修复请求`	Reads and validates the QA repair-request comment, appends development acceptance, then enters the existing repair chain; final status is `已修复` with merge evidence or `暂不修复` with approval evidence
`处理发布回流`	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 direct 开发任务:任务=<ID> chain, its confirmed unchanged plan, 提交代码, 完成开发 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; 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. A direct 开发任务:任务=<ID> or its confirmed unchanged plan grants the named task's guarded implementation, submission, merge attempt and automatic completion handoff as one chain. An explicit 提交代码 grants the same automatic completion only when the post-submit classifier returns confirmed; likely requires one same-task confirmation, while incomplete grants no lifecycle state write. 完成开发, 完成修复bug:<BUG-ID>, 修复bug:<BUG-ID> and 处理测试修复请求：缺陷=<BUG-ID> remain valid focused entries. The special test-repair entry must first validate the structured QA request and does not weaken branch, validation, MR or status evidence gates. 完成开发 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 “deploy to test first” 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 + submit + direct merge attempt + completion handoff. 开始开发:任务=<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 the same one-click authority directly after the internal analysis and gates, without displaying or waiting on the plan. After implementation, validation and trusted-version gates pass, it must internally continue through the 完成开发 executor without asking for a second command. After an explicit 提交代码 reaches a verified remote version, run the completion-readiness classifier: confirmed continues automatically, likely asks once with the exact task and evidence gap, and incomplete stops without suggesting completion. A user reply such as 是 or 执行完成开发 to that pending same-task prompt authorizes the completion executor; unrelated or later ambiguous replies do not. 完成开发 remains a focused recovery entry. 处理测试修复请求：缺陷=<BUG-ID> grants guarded request acceptance followed by the existing 修复bug chain for that Bug only; it never skips validation, branch binding, MR merge or status evidence. 完成修复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.

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.
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.
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.
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.
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.
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.
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.
For 开发任务, accept the explicit work-item ID for read-only intake without requiring a 【开发】 title prefix. Prefer a direct requirement relation, then resolve the source requirement and scope from official task and project evidence. Before formal development writes, the live handoff gate must prove the task's project and parent delivery; a missing direct requirement association alone remains recoverable, but an unprovable or wrong parent cannot be waived as a traceability warning. Derive 新增 or 优化 and 前端、后端 or 全栈 from the resolved materials, never a similar title alone. 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.
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.
Run the scoped pre-write material gate in references/implementation-materials.md. Both optimization and new addition require complete, implementable business rules and acceptance criteria. Require a uniquely addressable canonical prototype only for page/interaction scope; backend-only APIs, scheduled jobs and data synchronization use the applicable interface/data contracts and examples, with prototype marked not applicable. A referenced link is not automatically mandatory: unreadable required or acceptance-critical material blocks the affected scope; unavailable optional background/visual references only produce a warning. Never downgrade a frozen required material to bypass the handoff gate. Compare local and online prototypes only when both are applicable and available.
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.
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.
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.
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.
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. Mini Program: skip developer self-test cases, automated tests, and real-page verification; record the skip in the response.
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 Mini Program, skip those developer-side tests. Do not create a formal test run, write a tester result, close Bugs, or advance test-stage requirement states.
开发任务 implementation completes at verified code and task evidence. Web also requires developer-side validation. Formal QA execution is later, but 完成开发 may close the development work item only after its unique 【测试】 task is ready and officially read back.
When the implementation substage of 开发任务 passes, write the managed next-stage block containing $yunxiao-development-delivery and 完成开发:任务=<开发任务编号>. In direct one-click mode, continue internally through guarded 提交代码 and the completion executor under the already granted same-task authority; the implementation substage itself does not bypass those nodes. A plan-only request still stops before writes, and 开始开发 alone grants no code submission. No mode grants production deployment.
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.
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. Mini Program: skip that completion revalidation. Do not fabricate formal QA evidence.
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, 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 test pipeline may run only after its pipeline identity, scope, API-package freshness and deployment baseline are verified; production pipelines and release repositories remain outside this Skill. After code delivery is officially read back, classify testDeliveryMode: explicit execute runs the separate test-pipeline executor and requires deployment-version read-back; explicit merge_only completes with merged-code evidence and records pending deployment/test handoff; absent choice asks once with both options. classify_completion_readiness.py emits auto_complete_and_test, auto_complete_merge_only, or ask_test_delivery; hard blockers still stop all completion writes.
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.
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.
When effort inputs are auditable, prepare one idempotent actual-effort transaction through projex-create-effort-record or projex-update-effort-record. When they are not, omit the optional effort stage and record 工时无可核验来源. Do not close the development work item yet.
Freeze a oneos.complete-development-plan/v1 plan and run skill-run yunxiao_cli_complete_development.py preflight --plan <计划JSON> --output <预检回执JSON>, followed by apply --preflight <预检回执JSON> --output <执行回执JSON>. Its fixed order is optional effort → mandatory test handoff → development task 已完成 → optional requirement 开发完成→待测试 → final read-backs. The test-handoff stage must already prove the unique test task's owner, managed scope, TASK_SUB parent and ASSOCIATED requirement before development closure executes. Neither command reads other lifecycle Skill installations or requires their versions to match. Existing handoff, trusted-version, validation, authorization and read-back gates remain mandatory. A failed critical stage writes a partial receipt and stops later stages; rerun resumes only completed stage boundaries. Details: references/complete-development-executor.md. 25.1. Keep the source 【交付】 task at 处理中. Do not require sibling development tasks or their effort records before this current scope runs the executor. 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. The delivery task remains a cross-stage container and is closed only by YunxiaoPM after production acceptance.
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 待测试.
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.
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 “comprehensive testing”. 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.
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.
The dedicated executor performs the development closure only after step 29 has passed, then performs the separate requirement transition toward 待测试 when the live workflow still requires it and reads all target objects back. If the requirement is already 待测试 or 测试中, treat that state as an idempotent continuation and do not roll it back. The completion path must carry an explicit test-delivery choice: execute invokes the separate test-pipeline executor only after pipeline identity and deployment baseline are confirmed; merge_only does not run a pipeline and records 待部署、待交付测试; an omitted choice asks once after MR merge. A successful pipeline is evidence only after the actual deployed version includes the merged revisions. Emit the formal handoff with the current scope and the selected state; do not fabricate a test result.
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; Mini Program 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.
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 验证人/验证者.
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.
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.
Complete a single Bug only after scoped development validation passes and the exact MR is officially read back as MERGED with a verifiable mergedRevision. Write a 【研发完成】 record containing repair summary, validation results, repository, target branch, MR and merge commit, and explicitly 待部署、待交付测试. Set only the Bug to 已修复, preserving verifier and owner, then read back status and record. The record format and evidence checks are defined in references/yunxiao-cli-bug-batch.md; single-Bug flow applies the same evidence requirements without changing its existing ownership policy. No test deployment is required here; QA must verify the actually deployed version before retest or closure.
For 修复负责人是我的所有Bug, run doctor --require-auth, freeze the exact project/current-user Bug snapshot, resolve repository and branch by step 34, and create oneos.yunxiao-cli-bug-delivery-plan/v2. Run preflight before code writes to verify Codeup IDs, permissions, branches and baseline evidence. Flow availability, trigger mode, number of pipelines and test deployment are not repair gates. Never bypass CLI authentication or Codeup protection.
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.
After local and combined validation passes, reconcile each group, create at most one local commit and push per group, and record the remote commit map. Run ensure-mrs then merge-mrs to create/reuse, associate, merge and read back exact MRs through CLI. The merge executor checks the source commit again immediately before merging. A failed group blocks its affected Bugs; no automatic test-pipeline action follows.
Build actual development validation evidence as oneos.bug-development-validation/v1 with per-Bug/group revision, passed checks, repair summary and hashed local report. Pass it and the CLI merge receipt to set-status --snapshot <快照> --target 已修复 --merge-evidence <合并回执> --validation-evidence <验证清单> --serial <BUG-ID>.... Re-read each MR before writing and verify status, owner, verifier and the managed description record afterward. Missing or invalid merge/validation evidence blocks writes; absence of Flow does not. Records declare pending deployment, pending test handoff and qaReady=false. State-write failures do not repeat Git operations.
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.
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.
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 and the complete-development executor validate supported data schemas and real task evidence, not other roles' local installations. Missing or different versions of YunxiaoPM, YunxiaoQA or release Skills on the developer's machine are not blockers. suiteVersion in plans and events identifies the data producer; it does not assert that five Skills are installed. Existing development-brain preflight remains unchanged; this removal does not package or waive that separate dependency.
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→需求. Missing branch/code/MR association results remain traceability warnings. Formal development start/completion is different: the official task project and unique parent delivery must match the frozen handoff; read the official parent relation when the detail omits it, and stop if that identity cannot be proven. Never confuse optional code-asset association with mandatory business-scope identity.
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 complete business and acceptance rules. Page/interaction scope also requires one canonical prototype; non-UI scope requires its applicable API/data/state contracts and examples, not a fabricated UI prototype. Missing duplicate attachments, optional visual aids or background links do not block. Required-material failures and implementation/acceptance-critical conflicts still stop the affected scope; preserve the frozen handoff's required declarations.
A Web development task cannot complete without proportionate developer-side automated and real-page verification against the implemented version; a Mini Program 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; Mini Program 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.
完成开发 lifecycle writes must run through yunxiao_cli_complete_development.py. The executor forbids lightweight-verification, requires a trusted delivery version and development validation evidence, restricts each stage's write-operation whitelist, and will not run the development status update until test-task readiness is verified.
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. Mini Program 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 code repair is validated and merged. It does not prove deployment or readiness for retest; keep 待部署、待交付测试 until a separate verified test delivery.
The one-click single-Bug command is exactly 修复bug:<BUG-ID> after $yunxiao-development-delivery; it orchestrates 开始修复bug, fix and verify,提交代码 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 perform zero commits, pushes, MRs, merges or deployments in the edit loop. After combined validation, submit and merge once per group. Both Web and Mini Program finish repair with merged-code evidence and pending deployment/test handoff; no automatic Flow action.
Use bundled official CLI adapters for current-user resolution, snapshots/status/read-back and Codeup branches/MRs/merges. Authentication, project identity, unsafe branches and code revision mismatches still block their affected actions. Flow configuration or run availability does not gate repair completion. Never expose credentials or bypass CLI via 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 development verification and actual merged-MR/version evidence. Do not close it or claim passing retest; deployment verification, retest and closure remain with the later test delivery and 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 normally a zero-write blocker and never authorizes visual or browser fallback. The only scoped transport exception is TestHub plan discovery during 完成开发: default directly to the official ListTestPlan JSON adapter; the known CLI Content-Type defect must never trigger a probe or plugin upgrade. Actual retryable JSON service/transport failures record plan-read-skipped and skip only formal plan/case validation while continuing mandatory test-task handoff. Authentication, authorization, argument, ownership and ambiguity failures remain blockers.

Return

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