smoke-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Smoke Check

冒烟测试

This skill is the gate between "implementation done" and "ready for QA hand-off". It runs the automated test suite, checks for test coverage gaps, batch-verifies critical paths with the developer, and produces a PASS/FAIL report.

The rule is simple: a build that fails smoke check does not go to QA. Handing a broken build to QA wastes their time and demoralises the team.

Output:

production/qa/smoke-[date].md

该技能是“开发完成”与“准备QA交接”之间的关卡。它会运行自动化测试套件，检查测试覆盖率缺口，与开发者批量验证关键路径，并生成通过/失败报告。

规则很简单：未通过冒烟测试的构建版本不得移交QA。将有问题的版本交给QA会浪费他们的时间，还会打击团队士气。

输出文件：

production/qa/smoke-[date].md

Parse Arguments

参数解析

Arguments can be combined:

/smoke-check sprint --platform console

Base mode (first argument, default:

sprint

```
sprint
```
— full smoke check against the current sprint's stories
```
quick
```
— skip coverage scan (Phase 3) and Batch 3; use for rapid re-checks

Platform flag (

--platform

, default: none):

```
--platform pc
```
— add PC-specific checks (keyboard, mouse, windowed mode)
```
--platform console
```
— add console-specific checks (gamepad, TV safe zones, platform certification requirements)
```
--platform mobile
```
— add mobile-specific checks (touch, portrait/landscape, battery/thermal behaviour)
```
--platform all
```
— add all platform variants; output per-platform verdict table

--platform

is provided, Phase 4 adds platform-specific batches and Phase 5 outputs a per-platform verdict table in addition to the overall verdict.

参数可以组合使用：

/smoke-check sprint --platform console

基础模式（第一个参数，默认值：

sprint

）：

```
sprint
```
— 针对当前迭代的用户故事执行完整冒烟测试
```
quick
```
— 跳过阶段3（覆盖率扫描）和第3批检查；用于快速重新验证

平台标识（

--platform

，默认值：无）：

```
--platform pc
```
— 添加PC端专属检查（键盘、鼠标、窗口模式）
```
--platform console
```
— 添加主机端专属检查（游戏手柄、电视安全区域、平台认证要求）
```
--platform mobile
```
— 添加移动端专属检查（触控、横竖屏切换、电池/散热表现）
```
--platform all
```
— 添加所有平台变体检查；输出按平台划分的结果表格

如果提供了

--platform

参数，阶段4会添加平台专属检查批次，阶段5除了整体结果外，还会输出按平台划分的结果表格。

Phase 1: Detect Test Setup

阶段1：检测测试环境配置

Before running anything, understand the environment:

Test framework check: verify
```
tests/
```
directory exists. If it does not: "No test directory found at
```
tests/
```
. Run
```
/test-setup
```
to scaffold the testing infrastructure, or create the directory manually if tests live elsewhere." Then stop.
CI check: check whether
```
.github/workflows/
```
contains a workflow file referencing tests. Note in the report whether CI is configured.
Engine detection: read
```
.claude/docs/technical-preferences.md
```
and extract the
```
Engine:
```
value. Store this for test command selection in Phase 2.
Smoke test list: check whether
```
production/qa/smoke-tests.md
```
or
```
tests/smoke/
```
exists. If a smoke test list is found, load it for use in Phase 4. If neither exists, smoke tests will be drawn from the current QA plan (Phase 4 fallback).
QA plan check: glob
```
production/qa/qa-plan-*.md
```
and take the most recently modified file. If found, note the path — it will be used in Phase 3 and Phase 4. If not found, note: "No QA plan found. Run
```
/qa-plan sprint
```
before smoke-checking for best results."

Report findings before proceeding: "Environment: [engine]. Test directory: [found / not found]. CI configured: [yes / no]. QA plan: [path / not found]."

在运行任何测试前，先了解当前环境：

测试框架检查：验证
```
tests/
```
目录是否存在。如果不存在：“未在
```
tests/
```
路径下找到测试目录。请运行
```
/test-setup
```
搭建测试基础设施，若测试文件存放在其他位置，请手动创建对应目录。”然后终止流程。
CI检查：检查
```
.github/workflows/
```
目录中是否包含引用测试的工作流文件。在报告中记录CI是否已配置。
引擎检测：读取
```
.claude/docs/technical-preferences.md
```
文件，提取
```
Engine:
```
对应的值。保存该值，用于阶段2选择测试命令。
冒烟测试列表检查：检查
```
production/qa/smoke-tests.md
```
或
```
tests/smoke/
```
是否存在。如果找到冒烟测试列表，加载它用于阶段4。如果两者都不存在，冒烟测试用例将取自当前QA计划（阶段4备选方案）。
QA计划检查：匹配
```
production/qa/qa-plan-*.md
```
文件，选取最近修改的文件。如果找到，记录其路径——将用于阶段3和阶段4。如果未找到，记录：“未找到QA计划。为获得最佳冒烟测试效果，请先运行
```
/qa-plan sprint
```
。”

在继续流程前报告检测结果：“环境：[引擎名称]。测试目录：[已找到/未找到]。CI已配置：[是/否]。QA计划：[路径/未找到]。”

Phase 2: Run Automated Tests

阶段2：运行自动化测试

Attempt to run the test suite via Bash. Select the command based on the engine detected in Phase 1:

Godot 4:

bash

godot --headless --script tests/gdunit4_runner.gd 2>&1

If the GDUnit4 runner script does not exist at that path, try:

bash

godot --headless -s addons/gdunit4/GdUnitRunner.gd 2>&1

If neither path exists, note: "GDUnit4 runner not found — confirm the runner path for your test framework."

Unity: Unity tests require the editor and cannot be run headlessly via shell in most environments. Check for recent test result artifacts:

bash

undefined

尝试通过Bash运行测试套件。根据阶段1检测到的引擎选择对应命令：

Godot 4：

bash

godot --headless --script tests/gdunit4_runner.gd 2>&1

如果GDUnit4运行器脚本未在该路径下找到，尝试：

bash

godot --headless -s addons/gdunit4/GdUnitRunner.gd 2>&1

如果两个路径都不存在，记录：“未找到GDUnit4运行器——请确认测试框架的运行器路径。”

Unity： Unity测试需要编辑器支持，在大多数环境中无法通过Shell无头运行。检查最近的测试结果文件：

bash

undefined

List most recent test results (bash) — on Windows PowerShell use the fallback below

列出最近的测试结果（bash）——Windows PowerShell环境使用下方备选命令

ls -t test-results/ 2>/dev/null | head -5
|| powershell -Command "Get-ChildItem test-results/ -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 5 -ExpandProperty Name"

If test result files exist (XML or JSON), read the most recent one and parse
PASS/FAIL counts. If no artifacts exist: "Unity tests must be run from the
editor or CI pipeline. Please confirm test status manually before proceeding."

**Unreal Engine:**
```bash

如果存在测试结果文件（XML或JSON格式），读取最新的文件并解析通过/失败数量。如果没有结果文件：“Unity测试必须通过编辑器或CI流水线运行。请在继续前手动确认测试状态。”

**Unreal Engine：**
```bash

List most recent Unreal automation logs (bash) — on Windows PowerShell use the fallback below

列出最近的Unreal自动化测试日志（bash）——Windows PowerShell环境使用下方备选命令

ls -t Saved/Logs/ 2>/dev/null | grep -i "test|automation" | head -5
|| powershell -Command "Get-ChildItem Saved/Logs/ -ErrorAction SilentlyContinue | Where-Object { $_.Name -match 'test|automation' } | Sort-Object LastWriteTime -Descending | Select-Object -First 5 -ExpandProperty Name"

If no matching log found: "UE automation tests must be run via the Session
Frontend or CI pipeline. Please confirm test status manually."

**Unknown engine / not configured:**
"Engine not configured in `.claude/docs/technical-preferences.md`. Run
`/setup-engine` to specify the engine, then re-run `/smoke-check`."

**If the test runner is not available in this environment** (engine binary not
on PATH, runner script not found, etc.), report clearly:

"Automated tests could not be executed — engine binary not found on PATH.
Status will be recorded as NOT RUN. Confirm test results from your local IDE
or CI pipeline. Unconfirmed NOT RUN is treated as PASS WITH WARNINGS, not
FAIL — the developer must manually confirm results."

Do not treat NOT RUN as an automatic FAIL. Record it as a warning. The
developer's manual confirmation in Phase 4 can resolve it.

Parse runner output and extract:
- Total tests run
- Passing count
- Failing count
- Names of any failing tests (up to 10; if more, note the count)
- Any crash or error output from the runner itself

---

如果未找到匹配的日志：“UE自动化测试必须通过Session Frontend或CI流水线运行。请手动确认测试状态。”

**未知引擎/未配置引擎：**
“未在`.claude/docs/technical-preferences.md`中配置引擎。请运行`/setup-engine`指定引擎，然后重新运行`/smoke-check`。”

**如果当前环境无法运行测试运行器**（引擎二进制文件不在PATH中、运行器脚本未找到等），清晰报告：

“无法执行自动化测试——引擎二进制文件未在PATH中找到。状态将记录为未运行。请从本地IDE或CI流水线确认测试结果。未确认的未运行状态将被视为带警告通过，而非失败——开发者必须手动确认结果。”

不要将未运行状态自动判定为失败。将其记录为警告。开发者在阶段4的手动确认可以解决该问题。

解析运行器输出并提取：
- 总测试数量
- 通过数量
- 失败数量
- 失败测试的名称（最多10个；如果超过10个，记录数量）
- 运行器本身输出的任何崩溃或错误信息

---

Phase 3: Check Test Coverage

阶段3：检查测试覆盖率

Draw the story list from, in priority order:

The QA plan found in Phase 1 (its Test Summary table lists expected test file paths per story)
The current sprint plan from
```
production/sprints/
```
(most recently modified file)
If the
```
quick
```
argument was passed, skip this phase entirely and note: "Coverage scan skipped — run
```
/smoke-check sprint
```
for full coverage analysis."

For each story in scope:

Extract the system slug from the story's file path (e.g.,
```
production/epics/combat/story-001.md
```
→
```
combat
```
)
Glob
```
tests/unit/[system]/
```
and
```
tests/integration/[system]/
```
for files whose name contains the story slug or a closely related term
Check the story file itself for a
```
Test file:
```
header field or a "Test Evidence" section

Assign a coverage status to each story:

Status	Meaning
COVERED	A test file was found matching this story's system and scope
MANUAL	Story type is Visual/Feel or UI; a test evidence document was found
MISSING	Logic or Integration story with no matching test file
EXPECTED	Config/Data story — no test file required; spot-check is sufficient
UNKNOWN	Story file missing or unreadable

MISSING entries are advisory gaps. They do not cause a FAIL verdict but must appear prominently in the report and must be resolved before

/story-done

can fully close those stories.

按优先级从以下来源获取用户故事列表：

阶段1中找到的QA计划（其测试摘要表格列出了每个用户故事对应的预期测试文件路径）
```
production/sprints/
```
中的当前迭代计划（最近修改的文件）
如果传递了
```
quick
```
参数，完全跳过该阶段并记录：“已跳过覆盖率扫描——运行
```
/smoke-check sprint
```
以获取完整覆盖率分析。”

针对每个范围内的用户故事：

从用户故事的文件路径中提取系统标识（例如：
```
production/epics/combat/story-001.md
```
→
```
combat
```
）
匹配
```
tests/unit/[system]/
```
和
```
tests/integration/[system]/
```
目录中名称包含用户故事标识或相关术语的文件
检查用户故事文件本身是否包含
```
Test file:
```
头字段或“测试证据”章节

为每个用户故事分配覆盖率状态：

状态	含义
COVERED（已覆盖）	找到与该用户故事的系统和范围匹配的测试文件
MANUAL（手动测试）	用户故事类型为视觉/体验或UI；已找到测试证据文档
MISSING（缺失）	逻辑或集成类用户故事，无匹配测试文件
EXPECTED（无需测试）	配置/数据类用户故事——无需测试文件；抽查即可
UNKNOWN（未知）	用户故事文件缺失或无法读取

缺失条目是建议性缺口。它们不会导致失败判定，但必须在报告中突出显示，且在

/story-done

完全关闭这些用户故事前必须解决。

Phase 4: Run Manual Smoke Checks

阶段4：执行手动冒烟检查

Draw the smoke test checklist from, in priority order:

The QA plan's "Smoke Test Scope" section (if QA plan was found in Phase 1)
```
production/qa/smoke-tests.md
```
(if it exists)
```
tests/smoke/
```
directory contents (if it exists)
The standard fallback list below (used only when none of the above exist)

Tailor batches 2 and 3 to the actual systems identified from the sprint or QA plan. Replace bracketed placeholders with real mechanic names from the current sprint's stories.

Use

AskUserQuestion

to batch-verify. Keep to at most 3 calls.

Batch 1 — Core stability (always run):

question: "Core stability — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
  - "Game does not launch or crashes before reaching the main menu"
  - "New game / session fails to start"
  - "Main menu does not respond to inputs"
  - "Crash or hang observed during basic navigation"

For any selected item, ask the user to briefly describe what failed before generating the report.

Batch 2 — Sprint changes and regression (always run):

question: "Sprint changes and regression — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
  - "[Primary mechanic this sprint] — FAILED"
  - "[Second notable change this sprint, if any] — FAILED"
  - "Regression in a previous sprint's feature — FAILED"
  - "Other unexpected breakage observed — FAILED"

For any selected item, ask the user to briefly describe what broke before generating the report.

Batch 3 — Data integrity and performance (run unless
quick
argument):

question: "Data integrity and performance — select any items that FAILED or were skipped (leave all unselected if everything passed):"
multiSelect: true
options:
  - "Save / load — FAILED (data loss or corruption observed)"
  - "Save / load — N/A (save system not yet implemented)"
  - "Frame rate drops or hitches observed — FAILED"
  - "Performance not checked this session"

For any FAILED item selected, ask the user to describe what broke before generating the report.

Record each response verbatim for the Phase 5 report.

Platform Batches (run only if
--platform
argument was provided):

PC platform (

--platform pc

--platform all

question: "PC Platform — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
  - "Keyboard controls — FAILED (describe issue after)"
  - "Mouse input or cursor visibility — FAILED (describe issue after)"
  - "Windowed / fullscreen mode — FAILED (describe issue after)"
  - "Resolution change — FAILED (describe issue after)"

For any selected item, ask the user to briefly describe what failed before generating the report.

Console platform (

--platform console

--platform all

question: "Console Platform — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
  - "Gamepad input — FAILED (describe issue after)"
  - "UI outside TV safe zone / text clipped — FAILED (describe what is clipped after)"
  - "Keyboard/mouse fallback shown to gamepad user — FAILED (describe after)"
  - "Cold start (no prior save) — FAILED (describe issue after)"

For any selected item, ask the user to briefly describe what failed before generating the report.

Mobile platform (

--platform mobile

--platform all

question: "Mobile Platform — select any items that FAILED (leave all unselected if everything passed):"
multiSelect: true
options:
  - "Touch controls — FAILED (describe issue after)"
  - "Orientation change (portrait ↔ landscape) — FAILED (describe what breaks after)"
  - "Background / foreground transition (home button) — FAILED (describe issue after)"
  - "Performance / thermal throttling on target device — FAILED (describe after)"

For any selected item, ask the user to briefly describe what failed before generating the report.

按优先级从以下来源获取冒烟测试检查表：

QA计划中的“冒烟测试范围”章节（如果阶段1中找到QA计划）
```
production/qa/smoke-tests.md
```
（如果存在）
```
tests/smoke/
```
目录内容（如果存在）
下方的标准备选列表（仅当上述来源都不存在时使用）

根据迭代或QA计划中确定的实际系统调整第2和第3批检查。将括号中的占位符替换为当前迭代用户故事中的实际机制名称。

使用

AskUserQuestion

进行批量验证。最多调用3次。

第1批——核心稳定性（始终执行）：

question: "核心稳定性——选择任何失败的项（全部通过则不选）："
multiSelect: true
options:
  - "游戏无法启动或在进入主菜单前崩溃"
  - "新游戏/会话无法开始"
  - "主菜单不响应输入"
  - "基础导航过程中出现崩溃或卡顿"

对于任何选中的项，在生成报告前请用户简要描述失败情况。

第2批——迭代变更与回归（始终执行）：

question: "迭代变更与回归——选择任何失败的项（全部通过则不选）："
multiSelect: true
options:
  - "[本次迭代核心机制]——失败"
  - "[本次迭代次要变更（如有）]——失败"
  - "之前迭代功能出现回归——失败"
  - "出现其他意外故障——失败"

对于任何选中的项，在生成报告前请用户简要描述故障情况。

第3批——数据完整性与性能（除非传递
quick
参数，否则执行）：

question: "数据完整性与性能——选择任何失败或跳过的项（全部通过则不选）："
multiSelect: true
options:
  - "保存/加载——失败（观察到数据丢失或损坏）"
  - "保存/加载——不适用（保存系统尚未实现）"
  - "观察到帧率下降或卡顿——失败"
  - "本次会话未检查性能"

对于任何选中的失败项，在生成报告前请用户描述故障情况。

逐字记录每个响应，用于阶段5的报告。

平台专属批次（仅当提供

--platform

参数时执行）：

PC平台（

--platform pc

或

--platform all

）：

question: "PC平台——选择任何失败的项（全部通过则不选）："
multiSelect: true
options:
  - "键盘控制——失败（后续描述问题）"
  - "鼠标输入或光标可见性——失败（后续描述问题）"
  - "窗口/全屏模式——失败（后续描述问题）"
  - "分辨率切换——失败（后续描述问题）"

对于任何选中的项，在生成报告前请用户简要描述失败情况。

主机平台（

--platform console

或

--platform all

）：

question: "主机平台——选择任何失败的项（全部通过则不选）："
multiSelect: true
options:
  - "游戏手柄输入——失败（后续描述问题）"
  - "UI超出电视安全区域/文本被截断——失败（后续描述被截断内容）"
  - "向手柄用户显示键盘/鼠标 fallback 选项——失败（后续描述）"
  - "冷启动（无先前存档）——失败（后续描述问题）"

对于任何选中的项，在生成报告前请用户简要描述失败情况。

移动平台（

--platform mobile

或

--platform all

）：

question: "移动平台——选择任何失败的项（全部通过则不选）："
multiSelect: true
options:
  - "触控控制——失败（后续描述问题）"
  - "横竖屏切换——失败（后续描述故障）"
  - "后台/前台切换（主页按钮）——失败（后续描述问题）"
  - "目标设备上的性能/热节流——失败（后续描述）"

对于任何选中的项，在生成报告前请用户简要描述失败情况。

Phase 5: Generate Report

阶段5：生成报告

Assemble the full smoke check report:

markdown

undefined

组装完整的冒烟测试报告：

markdown

undefined

Smoke Check Report

冒烟测试报告

Date: [date] Sprint: [sprint name / number, or "Not identified"] Engine: [engine] QA Plan: [path, or "Not found — run /qa-plan first"] Argument: [sprint | quick | blank]

日期：[日期] 迭代：[迭代名称/编号，或“未识别”] 引擎：[引擎名称] QA计划：[路径，或“未找到——请先运行/qa-plan”] 参数：[sprint | quick | 无]

Automated Tests

自动化测试

Status: [PASS ([N] tests, [N] passing) | FAIL ([N] failures) | NOT RUN ([reason])]

[If FAIL, list failing tests:]

```
[test name]
```
— [brief failure description from runner output]

[If NOT RUN:] "Manual confirmation required: did tests pass in your local IDE or CI? This will determine whether the automated test row contributes to a FAIL verdict."

状态：[通过（[N]个测试，[N]个通过）| 失败（[N]个失败）| 未运行（[原因]）]

[如果失败，列出失败测试：]

```
[测试名称]
```
— [来自运行器输出的简短失败描述]

[如果未运行：] "需要手动确认：测试在本地IDE或CI中是否通过？这将决定自动化测试项是否会导致失败判定。"

Test Coverage

测试覆盖率

Story	Type	Test File	Coverage Status
[title]	Logic	`tests/unit/[system]/[slug]_test.[ext]`	COVERED
[title]	Visual/Feel	`tests/evidence/[slug]-screenshots.md`	MANUAL
[title]	Logic	—	MISSING ⚠
[title]	Config/Data	—	EXPECTED

Summary: [N] covered, [N] manual, [N] missing, [N] expected.

用户故事	类型	测试文件	覆盖率状态
[标题]	逻辑	`tests/unit/[system]/[slug]_test.[ext]`	已覆盖
[标题]	视觉/体验	`tests/evidence/[slug]-screenshots.md`	手动测试
[标题]	逻辑	—	缺失 ⚠
[标题]	配置/数据	—	无需测试

摘要：[N]个已覆盖，[N]个手动测试，[N]个缺失，[N]个无需测试。

Manual Smoke Checks

手动冒烟检查

Missing Test Evidence

缺失测试证据

Stories that must have test evidence before they can be marked COMPLETE via

/story-done

[story title] (
```
[path]
```
) — Logic story has no test file. Expected location:
```
tests/unit/[system]/[story-slug]_test.[ext]
```

[If none:] "All Logic and Integration stories have test coverage."

在通过

/story-done

标记为完成前，必须补充测试证据的用户故事：

[用户故事标题]（
```
[路径]
```
）——逻辑类用户故事无测试文件。预期位置：
```
tests/unit/[system]/[story-slug]_test.[ext]
```

[如果无缺失：]“所有逻辑和集成类用户故事均已覆盖测试。”

Platform-Specific Results (only if
--platform
was provided)

平台专属结果（仅当提供

--platform

参数时显示）

Platform	Checks Run	Passed	Failed	Platform Verdict
PC	[N]	[N]	[N]	PASS / FAIL
Console	[N]	[N]	[N]	PASS / FAIL
Mobile	[N]	[N]	[N]	PASS / FAIL

Platform notes: [any platform-specific observations not captured in pass/fail]

Any platform with one or more FAIL checks contributes to the overall FAIL verdict.

平台	检查项数量	通过数量	失败数量	平台结果
PC	[N]	[N]	[N]	通过 / 失败
主机	[N]	[N]	[N]	通过 / 失败
移动	[N]	[N]	[N]	通过 / 失败

平台备注：[未被通过/失败状态捕获的平台专属观察结果]

任何包含一个或多个失败检查项的平台都会导致整体失败判定。

Verdict: [PASS | PASS WITH WARNINGS | FAIL]

最终结果：[通过 | 带警告通过 | 失败]

[Verdict rules — first matching rule wins:]

FAIL if ANY of:

Automated test suite ran and reported one or more test failures
Any Batch 1 (core stability) check returned FAIL
Any Batch 2 (primary sprint mechanic or regression check) returned FAIL

PASS WITH WARNINGS if ALL of:

Automated tests PASS or NOT RUN (developer has not yet confirmed)
All Batch 1 and Batch 2 smoke checks PASS
One or more Logic/Integration stories have MISSING test evidence

PASS if ALL of:

Automated tests PASS
All smoke checks in all batches PASS or N/A
No MISSING test evidence entries

---

[结果判定规则——匹配第一条规则即生效：]

失败如果存在以下任意情况：

自动化测试套件运行并报告一个或多个测试失败
第1批（核心稳定性）检查中有任意项失败
第2批（迭代核心机制或回归检查）中有任意项失败

带警告通过 如果满足以下所有条件：

自动化测试通过或未运行（开发者尚未确认）
第1批和第2批冒烟检查全部通过
一个或多个逻辑/集成类用户故事存在缺失测试证据

通过如果满足以下所有条件：

自动化测试通过
所有批次的冒烟检查全部通过或不适用
无缺失测试证据条目

---

Phase 6: Write and Gate

阶段6：写入报告与关卡判定

Present the full report in conversation, then ask:

"May I write this smoke check report to

production/qa/smoke-[date].md

Write only after approval.

After writing, deliver the gate verdict:

If verdict is FAIL:

"The smoke check failed. Do not hand off to QA until these failures are resolved:

[List each failing automated test or smoke check with a one-line description]

Fix the failures and run

/smoke-check

again to re-gate before QA hand-off."

If verdict is PASS WITH WARNINGS:

"Smoke check passed with warnings. The build is ready for manual QA.

Advisory items to resolve before running

/story-done

on affected stories: [list MISSING test evidence entries]

QA hand-off: share

production/qa/qa-plan-[sprint].md

with the qa-tester agent to begin manual verification."

If verdict is PASS:

"Smoke check passed cleanly. The build is ready for manual QA.

QA hand-off: share

production/qa/qa-plan-[sprint].md

with the qa-tester agent to begin manual verification."

在对话中展示完整报告，然后询问：

“是否允许我将此冒烟测试报告写入

production/qa/smoke-[date].md

？”

仅在获得批准后写入文件。

写入完成后，给出关卡判定结果：

如果结果为失败：

“冒烟测试未通过。在解决以下失败问题前，不得移交QA：

[列出每个失败的自动化测试或冒烟检查项及一行描述]

修复失败问题后，请重新运行

/smoke-check

以重新验证，再进行QA交接。”

如果结果为带警告通过：

“冒烟测试带警告通过。构建版本已准备好进入人工QA环节。

在对受影响用户故事运行

/story-done

前需解决的建议项：[列出缺失测试证据条目]

QA交接：将

production/qa/qa-plan-[sprint].md

分享给qa-tester agent以开始人工验证。”

如果结果为通过：

“冒烟测试顺利通过。构建版本已准备好进入人工QA环节。

QA交接：将

production/qa/qa-plan-[sprint].md

分享给qa-tester agent以开始人工验证。”

Collaborative Protocol

协作协议

Never treat NOT RUN as automatic FAIL — record it as NOT RUN and let the developer confirm status manually. Unconfirmed NOT RUN contributes to PASS WITH WARNINGS, not FAIL.
Never auto-fix failures — report them and state what must be resolved. Do not attempt to edit source code or test files.
PASS WITH WARNINGS does not block QA hand-off — it records advisory gaps for
```
/story-done
```
to follow up on.
quick
argument skips Phase 3 (coverage scan) and Phase 4 Batch 3. Use it for rapid re-checks after fixing a specific failure.
Use
```
AskUserQuestion
```
for all manual smoke check verification.
Never write the report without asking — Phase 6 requires explicit approval before any file is created.

切勿将未运行状态自动判定为失败——记录为未运行，让开发者手动确认状态。未确认的未运行状态将被视为带警告通过，而非失败。
切勿自动修复失败问题——报告问题并说明必须解决的内容。不要尝试编辑源代码或测试文件。
带警告通过不会阻止QA交接——它会记录建议性缺口，供
```
/story-done
```
后续跟进。
quick
参数会跳过阶段3（覆盖率扫描）和阶段4的第3批检查。用于修复特定故障后的快速重新验证。
所有手动冒烟检查验证均使用
```
AskUserQuestion
```
。
未经询问切勿写入报告——阶段6要求在创建任何文件前获得明确批准。

smoke-check

Original

Translation

Smoke Check

冒烟测试

Parse Arguments

参数解析

Phase 1: Detect Test Setup

阶段1：检测测试环境配置

Phase 2: Run Automated Tests

阶段2：运行自动化测试

List most recent test results (bash) — on Windows PowerShell use the fallback below

列出最近的测试结果（bash）——Windows PowerShell环境使用下方备选命令

List most recent Unreal automation logs (bash) — on Windows PowerShell use the fallback below

列出最近的Unreal自动化测试日志（bash）——Windows PowerShell环境使用下方备选命令

Phase 3: Check Test Coverage

阶段3：检查测试覆盖率

Phase 4: Run Manual Smoke Checks

阶段4：执行手动冒烟检查

Phase 5: Generate Report

阶段5：生成报告

Smoke Check Report

冒烟测试报告

Automated Tests

自动化测试

Test Coverage

测试覆盖率

Manual Smoke Checks

手动冒烟检查

Missing Test Evidence

缺失测试证据

Platform-Specific Results (only if
`--platform`
was provided)

平台专属结果（仅当提供
`--platform`
参数时显示）

Verdict: [PASS | PASS WITH WARNINGS | FAIL]

最终结果：[通过 | 带警告通过 | 失败]

Phase 6: Write and Gate

阶段6：写入报告与关卡判定

Collaborative Protocol

协作协议

smoke-check

Original

Translation

Smoke Check

冒烟测试

Parse Arguments

参数解析

Phase 1: Detect Test Setup

阶段1：检测测试环境配置

Phase 2: Run Automated Tests

阶段2：运行自动化测试

List most recent test results (bash) — on Windows PowerShell use the fallback below

列出最近的测试结果（bash）——Windows PowerShell环境使用下方备选命令

List most recent Unreal automation logs (bash) — on Windows PowerShell use the fallback below

列出最近的Unreal自动化测试日志（bash）——Windows PowerShell环境使用下方备选命令

Phase 3: Check Test Coverage

阶段3：检查测试覆盖率

Phase 4: Run Manual Smoke Checks

阶段4：执行手动冒烟检查

Phase 5: Generate Report

阶段5：生成报告

Smoke Check Report

冒烟测试报告

Automated Tests

自动化测试

Test Coverage

测试覆盖率

Manual Smoke Checks

手动冒烟检查

Missing Test Evidence

缺失测试证据

Platform-Specific Results (only if --platform was provided)

平台专属结果（仅当提供--platform参数时显示）

Verdict: [PASS | PASS WITH WARNINGS | FAIL]

最终结果：[通过 | 带警告通过 | 失败]

Phase 6: Write and Gate

阶段6：写入报告与关卡判定

Collaborative Protocol

协作协议

Platform-Specific Results (only if
`--platform`
was provided)

平台专属结果（仅当提供
`--platform`
参数时显示）