Imported from inernoro/prd_agent (.claude/skills/acceptance-scenario-orchestrator/SKILL.md). Install upstream with npx skills add inernoro/prd_agent --skill acceptance-scenario-orchestrator. Copyright stays with the author.

验收场景编排器

版本：v1.1.0 | 状态：已落地 | 触发：/验收场景、"PR 验收"、"每日验收"、"commit 验收"、"未发布分支验收"、"缺陷复测"

用途

Use this skill before create-visual-test-to-kb when the验收目标 is broader than a single linear page check. The output is an execution brief that tells the downstream acceptance skill exactly what to test, what to announce before testing, what evidence must be captured, and how to decide the final verdict.

This skill does not replace browser取证 or MAP归档. It is the scene planner and evidence contract for those steps.

For daily, PR, commit-range, release, or repeatedly disputed acceptance, run acceptance-test-design first. This skill consumes that design brief and turns it into executable browser/test units.

Rule Source SSOT

Before building the scenario plan, load the acceptance rule source in this order:

1. Repository SSOT when available: doc/rule.acceptance.map-enterprise.md, doc/rule.acceptance.ssot.md, doc/guide.acceptance.daily-sop.md, doc/guide.acceptance.report-evidence.md, doc/design.acceptance.knowledge-governance.md.
2. Skill-package fallback when the skill is installed outside this repository: references/rules/*.md and references/rules/manifest.json.
3. If neither source exists, fail closed and state that the acceptance rule source is missing. Do not invent a local substitute.

The doc/ files are authoritative. The bundled references/rules/ files are generated snapshots for marketplace/offline users. Preserve the upstream acceptance-test-design decisions unless the SSOT documents require a stricter correction.

The chain boundary is controlled by doc/rule.acceptance.map-enterprise.md section “验收链路总控矩阵”. This skill only orchestrates complex acceptance scenarios; it must not route daily-report requests into acceptance reports or let daily-report styling replace the CDS acceptance report structure.

Workflow

1. Classify the scenario.

   • Read references/scenario-matrix.md.
   • Pick one primary scenario and any secondary modifiers.
   • If the target is "昨天", resolve the exact Asia/Shanghai date range before collecting commits.

2. Build the acceptance scope.

   • If an acceptance-test-design brief exists, preserve its behavior assertions, impact model, fusion tests, proof strength scores, and coverage gaps. Do not flatten it into a page list.
   • For daily/yesterday runs, require the upstream brief to include the daily_scope.py inventory or an equivalent machine-collected scope. If it is missing, stop and ask the upstream step to run the inventory before choosing pages.
   • Map PRs and commits to functional modules.
   • Extract one or more change assertions from each PR/commit before choosing pages. A change assertion is the behavior the diff claims to change, such as knowledge-base sync retries failed pushes, image upload compresses large files, or MCP rejects non-AgentApiKey callers.
   • For every assertion, first find the user-visible surface that should reveal the change: page, breadcrumb, visible state, toast, table row, detail panel, error text, empty state, progress state, or absence of a forbidden action. This page-level proof is the primary evidence whenever the change can be perceived by a user.
   • Map every assertion to the smallest real workflow, endpoint, log, or persisted state that can prove that assertion. Do not substitute a nearby module page for the changed behavior.
   • Treat API, log, database, and file evidence as secondary evidence unless the change is truly invisible to users. If no page-level evidence is possible, state why and name the internal evidence that replaces it.
   • For each module, identify the real user page location as a breadcrumb, such as 首页 -> 导航 -> 百宝箱 -> 文件转换.
   • Include unpublished branches and preview environments when the user asks for "未发布状态", "昨天全部内容", or branch-specific acceptance.
   • Freeze target_sha for every unpublished branch and compare it with the deployed tested_sha. When they differ, first seek an existing commit-pinned, snapshot, or isolated preview. If the frozen SHA cannot be reproduced, mark the item unverifiable; current-HEAD health is not evidence for the frozen version.
   • Allow preview-environment test data with a clear prefix such as 每日验收-YYYY-MM-DD-... when the automation policy permits it. Never use production-destructive data paths.
   • Keep cds and CDS Agent separate. cds/ platform changes use CDS platform evidence: cdscli/API branch status, deploy/smoke result, preview routing, reports page, scheduler/self-update state, logs, or extra-services state. CDS Agent evidence means the prd-admin /cds-agent workbench or its runtime/session flow, and can only prove CDS Agent-specific assertions.
   • Mark items as runtime, visual, api, docs/rules, or environment-only.
   • For multi-stage foreground/background work, preserve the upstream continuity state matrix. Schedule normal, slow, failure, and recovery test units; do not flatten them into one final-state screenshot.
   • Compute a depth budget before testing: target date, commit count, PR count, module count, high-risk module count, planned evidence count, and whether the run is 广度冒烟, 深度验收, or 发布前阻断验收.
   • For daily/yesterday runs, do not allow a small set of entry screenshots to stand in for deep functional acceptance. If the budget cannot cover real workflows, label the run 广度冒烟 or mark uncovered items explicitly.
   • Compute a proportionality ceiling as well as a depth floor. The brief must say where testing stops: which low-risk rows are grouped, which are non-runtime, which are observation-only, and which are intentionally left to follow-up because more evidence would not change the current Verdict.
   • Do not let the scenario plan become a search for every possible imperfection. The plan should find meaningful product risk and user-visible failure, not manufacture noise.

3. Produce the指差法 execution brief. For every test unit, write this before opening the page:

   • 现在开测: PR number or commit range.
   • 归属模块: business module and changed files if useful.
   • 改动断言: the exact behavior claimed by the diff.
   • 页面位置: breadcrumb and final URL.
   • 测试目的: the claim being verified.
   • 预期结果: user-visible observable conditions that must appear before the test can pass.
   • 证据要求: page screenshot first, then API response, log, database state, or file evidence as corroboration.
   • 用户心智: what a user or reviewer should understand from the page before seeing internal evidence.
   • 状态序列: the expected task identity and visible states before, during, and after background transitions.
   • 等待预算: first-feedback and first-usable-result expectations, distinct from final background completion.
   • 局部更新指标: expected document boot, unload, history-write, and content-loader counts.
   • 证据来源: deterministic-fixture, preview-live, or integration-live; state exactly which claim each source can prove.
   • 停止条件: what evidence is sufficient for this unit and what would be over-testing.

   The brief must be verbose enough to execute safely:

   • Announce the expected result before testing. A step that says only "open page and observe" is not executable acceptance.
   • Write the breadcrumb as a human path, for example 主页 -> 导航 -> 百宝箱 -> 视觉分镜台, not only a URL.
   • Include the evidence minimum for the step: entry proof, action proof, result proof, API/log/state proof, or negative proof.
   • If one screenshot is expected to cover multiple assertions, list every covered assertion and why the screenshot has fusion value.
   • If a changed path cannot be safely executed, specify the exact reason, the fallback evidence, and the forced verdict downgrade.

4. Run create-visual-test-to-kb with the brief.

   • The downstream skill performs browser取证, screenshot marking, report writing, MAP归档, and share-link verification.
   • If execution discovers new scope drift, update the brief rather than silently changing the report conclusion.

5. Enforce the evidence chain.

   • Every verdict row must connect PR/commit -> changed files -> change assertion -> real workflow/API/state -> expected result -> actual evidence -> conclusion.
   • Evidence relevance is mandatory. If a commit changed sync behavior, test sync execution/result/logs; a screenshot of the list page is at most entry evidence and must not be used as the pass proof for sync.
   • User-facing changes must be judged page-first: the report must show the page state a user would see, then use API/log/state evidence to explain or corroborate it. Internal data without a visible user consequence is diagnostic evidence, not the main visual acceptance result.
   • A screenshot that only shows "something happened" is insufficient unless its caption and markings explain which claim it proves.
   • A pass cannot be based only on an environment being reachable.
   • A deep daily acceptance pass requires at least two evidence points for each high-risk runtime module: one user-path screenshot plus one result/API/negative-path proof.
   • A daily/yesterday report that claims 深度验收 or 深度复验 must plan at least 12 valid screenshots. Fewer screenshots may be valid for 广度冒烟, but the report title, top verdict, and summary must say so.

6. Write the report contract.

   • Start the rendered report with H1 plus 验收速览卡; put the final verdict in that card. This is the only meaning of "final verdict at the top".
   • In the first screen, separate 产品质量, 验收完整性, 综合结论, 发布建议, and 判定性质. Do not make one Verdict carry all five meanings.
   • Require a 根因链条 table for every conditional/fail, SHA drift, environment blocker, or archive failure. Its columns are 目标要求, 观察事实, 系统原因, 证据影响, 结论, and 关闭动作.
   • Use conditional when no product/core/acceptance-chain failure was observed and the only problem is incomplete coverage, an unverifiable frozen SHA, P2/P3, or another non-blocking risk. Use fail only for product failure, core-case failure, acceptance-chain failure, or a hard-gate failure, and name which one occurred.
   • After the速览卡, start the body with 昨日工作总结 for daily/yesterday acceptance, or 验收范围摘要 for PR/commit/single-scenario acceptance.
   • Do not add an in-body table of contents. Use a coverage matrix and section headings instead.
   • Include PR/commit 到结果映射 near the top.
   • Include 标记法则与验收标准.
   • Include 截图回读检查.
   • Ensure the速览卡 verdict matches the mapped results and the worst meaningful failed/conditional item.
   • Require content fullness. Daily/yesterday reports must contain enough narrative and table rows to explain the day, the covered modules, the uncovered modules, the evidence strength, and the downgrade reasons. A report that only has a few screenshots plus a short conclusion is not a valid daily acceptance report.
   • Require anti-omission wording. Each high-risk or runtime assertion must end as pass, conditional, fail, internal-only, non-runtime, or uncovered; no assertion can be left implicit.
   • Require a 规范一致性自测 section for daily/yesterday, disputed, or user-feedback-driven reports. It must answer: whether the actual report follows the selected skills, whether the depth label matches the evidence, and whether any new enterprise rule was applied only in prose but not in execution.
   • Require a 问题定位自测 section when the report lists P0/P1/P2 visual problems. Each problem must name the exact page area, blocking object, blocked object, user impact, and evidence link. For example, 右下缺陷通知卡遮挡知识库卡片操作区 is acceptable; 遮挡问题 is not.

Scenario Selection

Use these scenario names in the execution brief:

If multiple scenarios match, choose the narrowest scenario as primary and list the others as modifiers. For example, "昨天未发布分支验收" is primary daily-yesterday with modifier unpublished-branch.

Execution Brief Template

# 验收场景编排

## 场景
- 主场景:
- 修饰场景:
- 目标日期或范围:
- 验收环境:

## 范围收敛
| PR/commit | 归属模块 | 页面位置 | 变更类型 | 是否运行态 | 验收策略 |
|-----------|----------|----------|----------|------------|----------|

## 指差法开测清单
| 顺序 | 现在开测 | 归属模块 | 页面位置 | 测试目的 | 预期结果 | 证据要求 | 停止条件 |
|------|----------|----------|----------|----------|----------|----------|----------|

## 报告契约
- 产品质量:
- 验收完整性:
- 综合结论:
- 发布建议:
- 判定性质:
- 根因链条:
- PR/commit 到结果映射:
- 标记法则与验收标准:
- 截图回读检查:
- 规范一致性自测:
- 问题定位自测:
- 重试记录:
- 未覆盖项:

Hard Rules

• Page evidence comes first for user-facing work. API/log/database evidence may confirm the cause or result, but must not replace the page proof unless the report explicitly marks the item as non-visual/internal.
• Do not let a screenshot prove a claim unless the screenshot is read back and the report states what was seen.
• Do not let a PR or commit disappear from the report. If it is non-runtime, mark it as file/rule evidence instead of omitting it.
• Do not turn retry success into a clean pass. Record the first failure, retry action, second result, and final judgment.
• Do not use environment health as a substitute for feature acceptance.
• Do not call a daily/yesterday run 深度验收 when it only checks entry pages and a few API 200s. That is 广度冒烟.
• Do not use a nearby screen as proof for a changed behavior. 列表可见, 按钮可见, or 页面可达 only prove entry/availability unless the commit itself was about entry/availability.
• In daily/yesterday reports, evidence cells must be clickable: write full screenshot-name anchors such as [图01](#fig-01-login-home) instead of plain 图01. Legacy [图01](#fig-01) is normalized only when the figure number is unique; repeated figure numbers must use full anchors.
• Do not use the CDS Agent page as evidence for CDS platform changes. A row about CDS deploy/preview/reports/branch network/extra-services/self-update/scheduler/proxy must cite CDS platform proof, not /cds-agent. If both changed, split them into separate rows.
• Do not mark an assertion passed unless the evidence exercises the changed path or inspects the changed result state. Otherwise mark it 未覆盖 or 关联不足.
• Do not mark a high-risk module as deeply accepted without an action/result pair or a negative-path/API proof. High-risk modules include auth, async workers, uploads/compression, external downloads, deployment, state transitions, and data restore.
• Do not accept a multi-stage task from its final screenshot alone. The execution brief must cover normal, slow, failure, and recovery paths and record continuity metrics.
• Do not use injected completion to claim a live external integration passed. Pair fixture state-machine proof with preview/live integration evidence or downgrade the integration assertion.
• Do not publish a MAP report whose share link has not been opened and verified.
• Do not include an in-body table of contents for daily acceptance reports.
• Do not accept thin daily reports. If the report cannot teach a reviewer what changed, where it was tested, why the evidence is relevant, what was not covered, and why the verdict is downgraded, send it back for expansion before archiving.
• Do not use filler as fullness. More screenshots or repeated prose do not count unless they add source scope, expected result, actual result, evidence linkage, or risk explanation.
• Do not accept over-testing as rigor. If additional checks do not change the risk, proof strength, or Verdict, mark them out of scope or observation-only.
• Do not publish a visual defect that the reader cannot locate. P0/P1/P2 visual findings must link to a marked screenshot where the affected area is boxed or circled and the label states severity plus phenomenon.

References

• Read ../acceptance-test-design/SKILL.md first when the request is about daily/yesterday acceptance, PR/commit acceptance, evidence strength, impact coverage, fusion testing, or a failed/weak prior report.
• Read references/scenario-matrix.md when classifying a target or preparing the execution brief.
• Read references/evidence-contract.md when writing or reviewing the final report.

Collaboration With create-visual-test-to-kb

After this skill produces the execution brief, use create-visual-test-to-kb for browser取证 and MAP归档. Pass the brief into the report body so that the final report can be audited against the original scenario plan.