YunxiaoQA

Test Task (YunxiaoQA)

First automatic update of each day (mandatory, before other actions)

On the first triggering of this Skill on each local calendar day, first execute:

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

updated: the five Yunxiao lifecycle Skills have been uniformly updated; you must fully re-read this SKILL.md and the references needed this time before continuing.
skipped-today: already successfully updated today, continue directly.
in-progress: another related Skill is executing the same update, continue directly without concurrently repeating the update.
failed / unavailable / cooldown: give only a brief prompt and continue the current task; an update failure must not block Yunxiao work.
The shared update scope is fixed to the user-level global installation of YunxiaoPM、yunxiao-development-delivery、development-brain、YunxiaoQA、yunxiao-release-operations ; it must not be used to modify project-level Skills, business repositories, Yunxiao data, pipelines or the production environment. It is forbidden to manually forge or write the daily success status in advance.

Client: the same business rules support both Codex and Cursor; the installer is responsible for selecting the client directory, and lifecycle handover must not depend on the installation path.

Tester Yunxiao automation. Formal Skill name YunxiaoQA, selector $YunxiaoQA; external Chinese name Test Task. This Skill is self-contained；forbids fork / include / "alignment"yunxiao-requirement-lifecycle。

Division of labor with YunxiaoPM (Requirement Task)and the development delivery Skill: this Skill only does testing-sideread/write.

Yunxiao lifecycle suite version:10.2.15。

Plan mode gate (mandatory · for any Yunxiao write)

For any operation that changes Yunxiao (creating defects, changing status, closing tasks, attaching iterations, changing owners/verifiers, etc.), the Agent as the first stepmust:

SwitchMode → plan(Note: align parameters and the execution checklist first, then apply all at once after confirmation).
Switching projects: when the command carries 项目= or Plan point-selection; when YunxiaoPM is available its PJ may be reused. It is forbidden to silently use the wrong spaceIdentifier; after confirmation write assets/runtime-ids.json → project.last_selected。
The Plan must clearly state: project name + spaceId, command type, involved numbers, target status, owner/verifier, related objects,things that will not be done。
Before user confirmation / "execute": apply is forbidden.
After confirmation, switch back to Agent,execute the checklist in one go within the same round, then validate and report back all at once.

Exception: only 拉取测试任务 / 拉取待验缺陷 and when not changing status, Plan may be skipped. When the user provides a complete 完成测试：测试任务=...；需求=...；人工确认通过=是, that command itself is the authorization for this write; the script must still perform pre-checks on the object, relationships, currently logged-in test user and status boundaries, but must not require a second confirmation.

Forbidden: skipping Plan on the grounds of "parameters are complete" or a "fast path".

For details see references/plan-gate.md。

Source-of-truth model

【测试】= 交付子项（TASK_SUB→【交付】）；由开发 Skill 在提测时创建（本 Skill 不建）
缺陷     = Bug；**必须** ASSOCIATED→【测试】（关联项，非父子）；产品需求写入描述追溯（本期不做需求 ASSOCIATED API）
开发归属 = Bug 与【测试】的关系只证明测试范围，不决定代码分支。Bug 可先创建、后补【开发】；已唯一关联【开发】的 Bug 回到对应开发分支，无开发归属的 Bug 才由开发侧建立独立 `fix/<Bug编号>` 分支
验证者   = workitem.verifier；所有测试侧建单路径均=当前登录测试用户，禁止口令覆盖
本期负责人=同交付【开发】负责人
缺陷打开态 = 待确认（禁止再用「待处理」指缺陷）
查重/复用 = 优先编号；禁止只按模糊标题瞎改他人单
测试可改状态 = 已修复→已关闭 | 已修复→再次打开 |（闭环）【测试】→已完成
测试阶段状态 = 【测试】待处理→处理中→已完成；首个正式范围可使需求开发中/开发完成/待测试→测试中；只有需求范围聚合闭环才→测试完成
完成测试/人工确认通过 = “完成测试”内的测试人员显式特批分支；跳过部署/TestHub/QA manifest/未关闭缺陷/范围聚合业务门禁，但保留对象唯一、正式关系、当前用户、状态边界、活动缺陷快照、官方回读与幂等审计；不改任何Bug，不作为正式发布候选
测试不改     = 待确认/再次打开/处理中 → 已修复|暂不修复|处理中（开发侧）
【测试】任务打开态 = 待处理 / 处理中（任务状态名，与缺陷待确认不同）
产品不建迭代 = 本 Skill 只把已关闭缺陷挂到已有当期迭代；迭代按端分列，缺陷只并入与来源【交付】端侧标签一致的迭代
交付端       = 【交付】端侧标签 Web / 小程序（PC 视为 Web）；Web 走test流水线证据，小程序按 testPipeline=skipped 跳过流水线与自动化测试
发布候选真相 = 完成态【测试】+ 测试证据块 + 测试完成需求 + 正式关系
常量       = assets/runtime-ids.json（2026-07-27 01_ONEOS 已实网补齐）

External invocation (embedding the other party's full text within this Skill is forbidden)

Timing	Invocation
Personnel / Project catalog / General status	Read-only this Skill assets/runtime-ids.json; for missing items, query Yunxiao in real time by handover ID
PJ Yunxiao project point selection	Query the Yunxiao project in real time by Plan/passphrase and write the selected result back to this Skill's runtime configuration
Defect description template / localization matrix	This Skill references/bug-template.md · references/diagnosis.md
Mount point selection [Testing]/Requirements	references/anchor-selection.md · `scripts/list_bug_anchors.py`
Actual write API	references/live-api.md(01_ONEOS verified)
Test execution closed loop	references/test-execution.md · `scripts/yunxiao_cli_test_lifecycle.py` · `scripts/yunxiao_cli_bug_retest.py`
TestHub plan/case execution	references/yunxiao-cli-testhub.md · `scripts/yunxiao_cli_testhub.py`
List/create defect/transition scripts	scripts/README.md · The current closed loop preferentially uses `yunxiao_cli_test_lifecycle.py` / `yunxiao_cli_bug_retest.py` / `yunxiao_cli_testhub.py`；`list_*`、`create_bug.py`、`transit_bug.py`、`close_test_task.py` retained only as historical diagnostics; if the script enters `_auth.py` Cookie path must stop and switch back to the official CLI
Cross-platform script startup	references/runtime-launcher.md · `skill-run <script.py> [参数...]`

Daily testingPrefer this Skill; no need to mount English yunxiao-bug-triage(diagnostic points have been incorporated into this Skill).

Cross-Skill logical handover (mandatory)

Only accept/output formal Skill names, requirement/delivery/development/testing/release task IDs, current status, formal ASSOCIATED/TASK_SUB relationships, as well as test plans, test cases, defects, pipelines, reports, and idempotency evidence identifiers. To start testing, only accept tasks that have been uniquely located with formal relationships and consistent test scope; product handover packages, iterations, or deployment blocks are not mandatory; the version under test must be verified before actual execution. Completing testing still requires reading back formal acceptance and version evidence; for the current ordinary completion executor's oneos.handoff-evidence/v1 requirements, see the test execution instructions.
It is forbidden to locate, read, copy, or require the user to provide the installation directory of other Skills. This Skill only reads resources within its own package; when personnel, project, or status information is missing, query Yunxiao in real time by handover ID.
The upstream development formal name is yunxiao-development-delivery, the downstream release formal name is yunxiao-release-operations, the product rollback formal name is YunxiaoPM; the selector must use $<正式名称>。

Iron rules for write operations (prevent ID misjudgment · mandatory)

Historical incident: clicking the status menu in the browser mistakenly closed ONEOS-343 as ONEOS-309. Therefore:

Forbiddento use cursor-ide-browser / DOM clicks / "interactive nodes" to change Yunxiao status, assignee, associations, or iteration.
Only conventional write path: this Skill scripts/*.py. TestHub plans/cases/results preferentially go through the official Alibaba Cloud CLI; when the current CLI and public OpenAPI both lack the write capability to "plan existing cases", first returnCLI_CAPABILITY_GAPand make zero writes. Only when the user explicitly confirms in the Plan a one-time page completion of "specified test plan + specified existing cases" is it allowed to perform that single action in an isolated test plan; immediately afterward, the CLI must be used to read back the cases in the plan and update the results. This exception prohibits changing work item status, prohibits guessing interfaces, and prohibits extending to other plans.
Hard ID gate: passphrase ONEOS-xx → script --sn → serialNumber == exact match → apply → read back serialNumber|subject|from→to; if any is incorrect, stop immediately.
Start/record/complete testing: only use skill-run yunxiao_cli_test_lifecycle.py start|record|complete ...; when "complete testing" explicitly carries人工确认通过=是, internally switch to that script'smanual-complete; for per-Bug retest closure only use skill-run yunxiao_cli_bug_retest.py .... Normal paths maintain the original official CLI evidence gate;manual-completeonly validate security and audit boundaries and record skipped business gates. All writes must have official readback.skill-run Parse according to references/runtime-launcher.md .
Legacy closed-loop entry：close_test_task.pyhas been disabled and is fixed to reject writes;transit_test_lifecycle.pyretained as a legacy Cookie-compatible implementation but prohibited for new executions;闭环测试任务compatibility passwords must be transferred toyunxiao_cli_test_lifecycle.py completethe full gate.
The new Projex and TestHub closed loops allow only PAT/organization ID/official CLI. Legacy Cookie scripts may only be used for historical diagnostics,prohibitedswitching to browser point-and-click "makeshift closure".

Routing (read in full as needed)

Scenario	Module
Password surface	references/commands.md
Active identification / natural language commands / unique test task location	references/semantic-routing.md
Start testing / evidence / complete testing / release handoff	references/test-execution.md · references/test-scope-aggregation.md
Line 1/2 · state machine · reopen	references/defect-flow.md
Diagnosis · duplicate check · layered initial assessment	references/diagnosis.md
Special fix channel for test defects	references/bug-repair-channel.md · `scripts/yunxiao_cli_bug_repair_request.py`
Defect description template	references/bug-template.md
Plan confirmation checklist	references/plan-gate.md
Mount point selection	references/anchor-selection.md
Actual write API	references/live-api.md
Cross-platform script launcher	references/runtime-launcher.md

Password quick reference

拉取测试任务：状态=待处理|处理中；[项目=…]
开始测试：测试任务=ONEOS-xx；[需求=ONEOS-yy]
记录测试证据：测试任务=ONEOS-xx；证据清单=<JSON文件>
发起缺陷：标题=…；描述=…；测试任务=ONEOS-xx；[需求=ONEOS-yy]；[开发任务=ONEOS-zz]；[交付单元=ID]；[负责人=…]；[证据=…]
从测试用例发起缺陷：测试用例=CASE-xx；标题=…；描述=…；测试任务=ONEOS-xx；[需求=ONEOS-yy]；[开发任务=ONEOS-zz]；[交付单元=ID]；[负责人=…]；[证据=…]
发起缺陷(非本期)：标题=…；描述=…；负责人=…；[测试任务=…]；[项目=…]
提交缺陷修复请求：缺陷=ONEOS-xx；测试任务=ONEOS-yy；证据清单=<JSON文件>；描述=…
# 无测试任务的非本期须显式声明，默认仍要求挂测试子项+需求
拉取待验缺陷：状态=已修复|暂不修复；[测试任务=…]；[负责人=…]
批量关闭已修复：缺陷=ONEOS-a；复测用例=CASE-ID；复测执行=RUN-ID；test版本=VERSION；证据=ID或URL；验证人=当前用户
再次打开：缺陷=ONEOS-xx；[原因=复现说明]；[证据=…]
并入当期迭代：缺陷=… 或 范围=已关闭且未挂迭代；迭代=（当期/指定名）
完成测试：测试任务=ONEOS-xx；[需求=ONEOS-yy]；证据清单=<JSON文件>；[暂不修复批准=BUG-ID=批准人|证据]
完成测试：测试任务=ONEOS-xx；需求=ONEOS-yy；人工确认通过=是；[说明=测试人员确认通过]
接收发布回流：发版任务=TASK-900；触发=发布失败|产品验收失败；证据=ID或URL
验证发布回流：发版任务=TASK-900；缺陷=ONEOS-a,ONEOS-b；回归证据清单=<JSON文件>
闭环测试任务：测试任务=ONEOS-xx（兼容旧口令；按“完成测试”门禁执行）

Number first: password explicit ONEOS-xx > current context > ask;prohibited from guessing the number by title and then silently writing to Yunxiao。

For implicit invocations or when the user uses colloquial expressions, first read in fullactive identification and semantic routing, normalize the original words into existing passwords on this page; do not bypass Plan, number, relationship, evidence, and readback gates.

Initiate defect pipeline (mandatory · Option B)

Each time 发起缺陷 / 从测试用例发起缺陷 / 发起缺陷(非本期)：

Normalized evidence(environment, path, role, time, steps, actual/expected, screenshots; no secrets)
Duplicate check(active + recently closed; if same cause, update the old ticket and report back; if not asked, create new)
Layered initial assessment(frontend/backend/data/configuration/environment; mark as "inferred")
Fill template → see bug-template.md
Fields: verifier = currently logged-in test user, password override prohibited; current-period owner = the [development] owner of the same delivery (multiple people selected in Plan); non-current-period owner = password required
- Independent creation:create_bug.py --source standalone
- Test case creation:create_bug.py --source test-case --test-case <用例编号/执行记录>
- Both paths must enter the same ticket creation handler. After apply, use the current session user recorded by Yunxiao on the newly created Bug as the truth, write toworkitem.verifierand read back; do not substitute a fixed name, owner, developer, test supervisor, or password parameter. 5b. Mount point selection: when the password does not give a unique 测试任务= , first run list_bug_anchors.py, use AskQuestion to select [test]; requirements may be selected/traced, and writing into the description serves as tracing (not a linked item). If [test] is not selected, create is prohibited. See anchor-selection.md。
Association：
- Hard gate: defect on createlink ASSOCIATED→【测试】(linked item;prohibited TASK_SUB/parent-child); read back ASSOCIATED verification, exit code 3 on failure.
- Requirement: after click-through/traceability, write to the "Traced Requirement" section of the description;Do not do Cookie afterward ASSOCIATED→需求(do not alert, do not fake success). Password 需求= / --req can override.
- Development ownership hint: if a unique [Development] task already exists, its ID and deliveryUnitId can be written into the description traceability section, for the development side to select a branch; this is not a formal relationship, and if it does not exist it does not block creating the Bug. If the development task is created later, the development/product side supplements the formal relationship, then backfills via the delivery ledger DEVELOPMENT_TASK_AGGREGATED。
Plan echo → confirm → apply (create_bug.py) → read back current user = verifier and [Test] association → report; any verification failure must stop

Special fix channel for test defects

After test confirmation fails, you can use提交缺陷修复请求to write the reproduction steps, actual/expected, test task, case/execution record and evidence references into the Bug comment. This action only appends【测试缺陷修复请求】, does not change Bug status, does not change code;yunxiao_cli_bug_repair_request.pyit verifies the formal relationship between the Bug and [Test], the current status, evidence hash and current test user, and officially reads back the comment.

After the development side receives the request, it automatically enters处理测试修复请求：缺陷=ONEOS-xxspecial entry. The entry re-reads and verifies the latest request, assignee and status, appends【开发接收测试修复】comment, then directly reuses the existing修复bug:ONEOS-xxpipeline, without requiring the tester to describe the problem again. After code merge and development verification pass, mark已修复; if it is truly not handled, the reason, approver, approval evidence and follow-up actions must be submitted, and the development side marks暂不修复. Both statuses must be officially read back; the test side cannot change them on behalf of others.

Hard gate for test completion

Execute完成测试before it must simultaneously satisfy:

[Test]=处理中and formalTASK_SUB→【交付】、ASSOCIATED→需求. When receiving a task, verify the formal relationship and oneos.test-scope/v1, keep the manual description; before completion, according to the current qa-complete protocol read back the formal acceptance evidence. Starting testing does not mean the test passed, nor does it prove the environment is ready.
Requirement=测试中。
In development handoff, theoneos.test-deployment/v1block is routed bydeliveryEnd:Webindicates the version has been successfully deployed to test, and the project, iteration, requirement, test task, execution ID and deployment version are all consistent;Mini ProgramistestPipeline=skipped、status=skippedand containsreason, the project, iteration, requirement and test task are consistent, and test pipeline and automated test evidence are not required.
oneos.qa-evidence/v1The evidence list has been read and verified from real test assets, including plan ID/URL, case execution ID/URL, report ID/URL, test deployment execution and SHA-256; it is forbidden to substitute chat parameters, self-filled "0 failures" or placeholder links.
The cases selected for the current test scope have no unexecuted, failed or blocked items, and the scope count is closed; the total count of the entire requirement plan must not be used to replace the current end scope.
No待确认/处理中/已修复/再次打开defects; each closed Bug carries independentoneos.bug-retest/v1retest pass evidence.
Each暂不修复defect has a clear approver and evidence; status alone without approval evidence still blocks.
After the evidence block is written and read back, first advance the current [Test] →已完成; only--aggregate-completeand only when all associated development/testing scopes are closed-loop, advance the requirement →测试完成。
Output the project, required iteration, requirement, delivery, test task, deployment version, defect status, evidence checklist hash, completion time, and idempotency key, and hand them to$yunxiao-release-operationsto form a release batch.
qa-complete Only accept development/testing understanding receipts that are fully consistent with the current scope, current delivery version, and current managed manifest;requiredAcceptanceIds must be qaResult.cases exactly covered and all PASS, any NOT_RUN, old contract hash, missing receipt, or PENDING engineering decision that would block QA results in zero writes. "Release tonight" or "save tokens" does not constitute an exception.

完成测试explicit in人工确认通过=是is only an administrative status cleanup exception: deployment evidence, TestHub plans/cases, QA manifest, handoff bundle, or defect closure may not be required, but one-to-one mapping between development tasks and test tasks and requirement scope aggregation must not be skipped. Only after all non-canceled development tasks have a unique test task and sibling test tasks are completed, advance the current [Test] to已完成and advance the requirement to测试完成. The current logged-in test user, time, description, idempotency key, skipped items, scope aggregation, and associated defect snapshot must be written tooneos.qa-manual-complete/v1and read back; associated bugs remain as they are, forgery as ordinary test evidence is prohibited, and the handoff is marked as formal:false. Downstream release must reject this result; "release first and supplement later" does not change its informal nature.

This Skill's endpoint and explicit non-goals

Endpoint: Complete test execution and defect closure, advance the requirement to test completion, and output a machine-verifiable release candidate handoff.
Explicit non-goals: Create [Development]/[Test] tasks, mark "Fixed/Won't Fix" on behalf of development, create iterations, change product/development phase status, attach repositories/create branches/submit MRs.
This Skill explicitly owns and only owns the requirement testing phase待测试→测试中→测试完成。

Defect reflow handoff: "On the development side, please use the development Skill to pull pending-confirmation/reopened defects and mark them Fixed|Won't Fix." Test completion handoff: "On the release side, please use$yunxiao-release-operationsto form a release batch."

After release or product acceptance failure, formal reflow followsrelease-repair-loop.md; do not directly rerun production or directly accept again.

Acceptance checklist (report self-check)

Pull [Test]: only pending/in progress (or specified by passphrase)
Start testing: [Test] pending → in progress; requirement pending test → testing; both sides read back
Create defect (standalone/test case): verifier = current logged-in user and read back; assignee/association correct; passes duplicate check + template
Bug branch hint: test relationship is not mistaken for development ownership; if there is a unique development task, keep the hint; if there is no development task, still create the Bug normally
Reopen: only from "Fixed" and with reproduction description; assignee not mistakenly changed
Batch close: per-Bug retest evidence has been written and read back; only "Fixed" → "Closed"
Merge into iteration: only "Closed"; iteration already exists (not newly created)
Complete testing: test deployment and QA evidence checklist have been verified, evidence block has been written and read back; all associated defects are closed-loop; all Won't Fix items have approval evidence
Complete testing/manual confirmation passed: current test user, description, skipped items, defect snapshot, and idempotency key have been written and read back; Bug has not been modified; marked as informal release candidate
State closed loop: [Testing] In Progress → Completed; Requirement testing → Testing completed; both sides read back
Release handoff: project/iteration/requirement/delivery/test evidence/idempotency key complete
Each write operation report contains one line:serialNumber | subject | from→to(consistent with the command number)
This round has no browser status changes; no [Development] created, no iteration created, no status changed on behalf of development

The difference between Bug fixed and retestable

Development side已修复It only proves the code passed development verification and has been merged, may still be待部署、待交付测试. Before QA starts actual retesting, writes a retest conclusion, or closes the Bug, it must verify the real test deployment and that the version under test contains the fix; the fixed status oroneos.bug-fix-evidence/v1must not be used as a substitute for deployment evidence. The existing retest executor's deployment evidence verification remains unchanged.