finalrun-generate-test

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

FinalRun Test and Suite Generator

FinalRun 测试与套件生成器

You are an expert QA Automation Engineer. Generate FinalRun YAML artifacts with extreme precision. This skill guides you through planning new testing campaigns, finding existing test assets grouped by feature, presenting a proposed plan to the user, and saving approved tests in strict YAML format.

你是一名专业的QA自动化工程师，需要以极高的精度生成FinalRun YAML产物。本技能将指导你规划新的测试活动、查找按功能分组的现有测试资产、向用户展示拟定的测试计划，以及将通过审核的测试用例严格按照YAML格式保存。

Core Principles

核心原则

Test user-facing functionality only:

✅ User interactions, gestures, and navigation (tap, swipe, scroll, back navigation)
✅ End-to-end screen and feature functionality
✅ Form input, validation, search, filters, and interactive UI elements
✅ Mobile-specific behaviors (keyboard input, screen transitions, orientation changes)
❌ APIs, backend endpoints, or server-side logic
❌ Validating third-party authentication provider internals (OAuth, Google, Facebook, GitHub)

Variables & secrets (no hardcoding):

Prerequisite: The finalrun
CLI must be installed and available on
```
PATH
```
(the same binary the user will use to run tests). Declarations in
```
.finalrun/env/<env>.yaml
```
are validated and resolved by finalrun check
and at run time; without the CLI you cannot confirm bindings are correct.
NEVER guess or fabricate credentials, emails, passwords, or account-specific values.
NEVER hardcode plaintext secrets into a test file.
Use
```
${variables.KEY}
```
and
```
${secrets.KEY}
```
in tests. Both must be declared under
```
variables
```
and
```
secrets
```
in
```
.finalrun/env/<env>.yaml
```
(one file per environment name).
Secrets in YAML use the FinalRun form
```
secrets.logical_key: "${SHELL_ENV_VAR}"
```
(placeholder only). Real values are supplied by the shell or CI environment at
```
finalrun check
```
and run time.
Do not assert or require that
```
.finalrun/.env.*
```
files exist; do not treat secret storage files as part of validation. Do not read or write
```
.env.*
```
files.

App configuration (required):

FinalRun runs require
```
.finalrun/config.yaml
```
to define the default app identity for the repo.
Use
```
app.packageName
```
for Android and
```
app.bundleId
```
for iOS.
Infer app identifiers from the codebase before asking the user to type them manually.
Treat repo inspection as autofill, not silent truth: propose what you found and ask only when the repo is ambiguous.
Ask whether the app identifier changes by environment.
If the identifier is the same everywhere, keep app identity only in
```
.finalrun/config.yaml
```
.
If the identifier differs by environment, keep the default app identity in
```
.finalrun/config.yaml
```
and replace it with a full env-specific
```
app
```
block under
```
.finalrun/env/<env>.yaml
```
.

仅测试面向用户的功能：

✅ 用户交互、手势操作与导航（点击、滑动、滚动、返回导航）
✅ 端到端的页面与功能可用性
✅ 表单输入、校验、搜索、筛选与交互类UI元素
✅ 移动端专属行为（键盘输入、页面转场、横竖屏切换）
❌ API、后端接口或服务端逻辑
❌ 校验第三方认证提供商的内部逻辑（OAuth、Google、Facebook、GitHub）

变量与密钥（禁止硬编码）：

前置条件： 必须安装**
```
finalrun
```
CLI并添加到
PATH
中（和用户运行测试使用的二进制文件一致）。
.finalrun/env/<env>.yaml
中的声明会通过
```
finalrun check
```
**和运行时进行校验与解析；没有CLI的情况下你无法确认绑定关系是否正确。
绝对不要猜测或捏造凭证、邮箱、密码或账户专属数值。
绝对不要在测试文件中硬编码明文密钥。
在测试中使用
```
${variables.KEY}
```
和
```
${secrets.KEY}
```
。两者都必须在
```
.finalrun/env/<env>.yaml
```
的
```
variables
```
和
```
secrets
```
下声明（每个环境对应一个独立文件）。
YAML中的密钥使用FinalRun格式
```
secrets.logical_key: "${SHELL_ENV_VAR}"
```
（仅作为占位符）。真实值会在
```
finalrun check
```
和运行时由shell或CI环境注入。
不要断言或要求
```
.finalrun/.env.*
```
文件存在；不要将密钥存储文件视为校验的一部分。不要读写
```
.env.*
```
文件。

应用配置（必填）：

FinalRun运行需要
```
.finalrun/config.yaml
```
定义仓库的默认应用标识。
Android使用
```
app.packageName
```
，iOS使用
```
app.bundleId
```
。
优先从代码库中推导应用标识，再要求用户手动输入。
将仓库识别结果视为自动填充内容，而非绝对正确的信息：先向用户提议你找到的标识，仅当仓库信息模糊时再询问用户。
询问用户应用标识是否会随环境变化。
如果所有环境的标识都相同，仅在
```
.finalrun/config.yaml
```
中保存应用标识即可。
如果标识随环境变化，在
```
.finalrun/config.yaml
```
中保存默认应用标识，再在
```
.finalrun/env/<env>.yaml
```
中添加对应环境的完整
```
app
```
配置块覆盖默认值。

Workflow Steps

工作流步骤

Step 1 — Deep Dive & Analysis

步骤1 — 深度调研与分析

Read the user's request. Read relevant application source code to thoroughly understand the user-facing functionality, UI elements, and validation points that need to be tested.

阅读用户的需求，查阅相关应用源代码，全面理解需要测试的面向用户功能、UI元素和校验点。

Step 1A — Infer app identity (name, bundle ID, package name) from the repo

步骤1A — 从仓库推导应用标识（名称、bundle ID、package name）

Inspect the code base files and infer them when possible. take decision on whether the repo of for android, ios or cross-platform. If you find multiple identifiers, propose the best candidate and ask the user to confirm which one is correct. If the repo structure makes it clear that different environments use different app identifiers, propose the inferred values for each env and ask the user to confirm.

Inference rules:
- If one identifier is clearly the repo default, write it to
```
.finalrun/config.yaml
```
  .
- If env-specific identifiers are clearly derivable, keep the default in
```
.finalrun/config.yaml
```
  and put only the differing value in
```
.finalrun/env/<env>.yaml
```
  .
- Reuse existing env names from
```
.finalrun/env/*.yaml
```
  before inventing new ones.
Guardrails:
- Do not treat Android
```
namespace
```
  as the app package unless there is no better source.
- Do not infer env names from every flavor automatically;
```
free
```
  /
```
paid
```
  are not the same as
```
dev
```
  /
```
staging
```
  /
```
prod
```
  .
- Do not silently overwrite an existing
```
.finalrun/config.yaml
```
  app block. Show the proposed change first.
- Ask the user only when multiple app modules/targets are plausible or the identifiers cannot be resolved confidently.

检查代码库文件，尽可能推导标识。判断仓库是面向Android、iOS还是跨平台。如果找到多个标识，提议最优候选值并请用户确认正确的选项。如果仓库结构明确显示不同环境使用不同应用标识，提议为每个环境推导的数值并请用户确认。

推导规则：
- 如果有一个标识明显是仓库默认值，将其写入
```
.finalrun/config.yaml
```
  。
- 如果可以明确推导环境专属标识，在
```
.finalrun/config.yaml
```
  中保留默认值，仅将不同的数值写入
```
.finalrun/env/<env>.yaml
```
  。
- 优先复用
```
.finalrun/env/*.yaml
```
  中已有的环境名称，不要随意创建新名称。
防护规则：
- 除非没有更可靠的来源，否则不要将Android的
```
namespace
```
  视为应用包名。
- 不要自动从每个构建变体推导环境名称；
```
免费版
```
  /
```
付费版
```
  和
```
dev
```
  /
```
staging
```
  /
```
prod
```
  不是同一概念。
- 不要静默覆盖已有的
```
.finalrun/config.yaml
```
  应用配置块，先向用户展示拟修改的内容。
- 仅当存在多个合理的应用模块/目标，或者无法明确解析标识时，再询问用户。

Step 2 — Environment profiles (required when tests use

${variables.*}

${secrets.*}

, or when app identity differs by environment)

步骤2 — 环境配置文件（当测试使用

${variables.*}

或

${secrets.*}

，或应用标识随环境变化时必填）

Inspect: Read
```
.finalrun/config.yaml
```
and
```
.finalrun/env/*.yaml
```
if present so you reuse the existing app config and binding keys.
Scaffold: If the folder is missing or empty, create the env files the user needs (ask which names:
```
dev
```
,
```
staging
```
,
```
prod
```
, …) only when the tests need env-specific bindings or env-specific app overrides.
App setup:
- Ensure
```
.finalrun/config.yaml
```
  has the default repo app identity.
- Prefer repo-derived app identity over manual entry whenever the codebase makes it clear.
- Ask whether the app identifier changes by environment only if the repo structure does not make that obvious.
- If yes, add only the env-specific
```
app
```
  override to
```
.finalrun/env/<env>.yaml
```
  .
- If no, keep the app identity only in
```
.finalrun/config.yaml
```
  .
Declare bindings in YAML:
- Add
```
variables.*
```
  for non-secret values used in tests.
- Add
```
secrets.*
```
  as
```
"${ENV_VAR}"
```
  placeholders (choose stable
```
ENV_VAR
```
  names; document which exports the user must set).
Which env files to update: Ask the user. Default recommendation: add the same keys to every
```
.finalrun/env/*.yaml
```
so all environments stay aligned unless they explicitly want a subset.
Allowed env file shapes:
```
.finalrun/env/<env>.yaml
```
may contain
```
app
```
,
```
variables
```
,
```
secrets
```
, or any combination of them.

Recommended generated config shapes:

Same package everywhere:

yaml

app:
  name: ExampleApp
  packageName: com.example.app
  bundleId: com.example.app

Different package by environment:

yaml

app:
  name: ExampleApp
  packageName: com.example.app
  bundleId: com.example.app

yaml

app:
  packageName: com.example.app.staging
  bundleId: com.example.app.staging

检查： 如果存在
```
.finalrun/config.yaml
```
和
```
.finalrun/env/*.yaml
```
，先读取这些文件，复用已有的应用配置和绑定键。
搭建框架： 如果文件夹缺失或为空，仅当测试需要环境专属绑定或环境专属应用覆盖时，创建用户需要的环境文件（询问用户需要的名称：
```
dev
```
、
```
staging
```
、
```
prod
```
等）。
应用设置：
- 确保
```
.finalrun/config.yaml
```
  包含仓库的默认应用标识。
- 只要代码库信息明确，优先使用从仓库推导的应用标识，而非手动输入。
- 仅当仓库结构未明确说明时，再询问用户应用标识是否随环境变化。
- 如果是，仅将环境专属的
```
app
```
  覆盖配置添加到
```
.finalrun/env/<env>.yaml
```
  。
- 如果否，仅在
```
.finalrun/config.yaml
```
  中保留应用标识即可。
在YAML中声明绑定：
- 为测试中使用的非保密数值添加
```
variables.*
```
  配置。
- 以
```
"${ENV_VAR}"
```
  占位符的形式添加
```
secrets.*
```
  配置（选择稳定的
```
ENV_VAR
```
  名称；说明用户需要导出的变量）。
需要更新哪些环境文件： 询问用户。 默认建议：将相同的键添加到所有
```
.finalrun/env/*.yaml
```
中，确保所有环境配置对齐，除非用户明确希望仅添加到部分环境。
允许的环境文件结构：
```
.finalrun/env/<env>.yaml
```
可以包含
```
app
```
、
```
variables
```
、
```
secrets
```
或以上任意组合。

推荐生成的配置结构：

所有环境使用相同包名：

yaml

app:
  name: ExampleApp
  packageName: com.example.app
  bundleId: com.example.app

不同环境使用不同包名：

yaml

app:
  name: ExampleApp
  packageName: com.example.app
  bundleId: com.example.app

yaml

app:
  packageName: com.example.app.staging
  bundleId: com.example.app.staging

Step 3 — Planning & Folder Discovery

步骤3 — 规划与文件夹探查

Before creating any test code, you must look into the existing test directories to avoid duplicates and adhere to feature-based grouping.

Inspect the
```
.finalrun/tests/
```
directory. Tests are grouped into sub-folders matching feature names (e.g.,
```
.finalrun/tests/<feature-name>/
```
).
Search for a feature folder relevant to the current request.
- If a relevant feature folder exists: Inspect the YAML files inside it.
  - If a relevant test already exists, plan an UPDATE to the existing file.
  - If a relevant test does not exist, plan to CREATE a new
```
.yaml
```
    file inside this folder.
- If no relevant feature folder exists: Plan to CREATE a new feature folder (e.g.,
```
.finalrun/tests/<new_feature_name>/
```
  ).
- If multiple feature folders appear potentially relevant: STOP. Ask the user to confirm which folder should represent the primary feature.
Repeat a similar process for test suites under
```
.finalrun/suites/
```
. Suite files should match the feature folder conceptually, typically
```
.finalrun/suites/<feature-name>.yaml
```
. Update an existing suite to include the new test(s) or create a new suite if none exists.

创建任何测试代码之前，必须查看已有的测试目录，避免重复，且遵守按功能分组的规则。

检查
```
.finalrun/tests/
```
目录。测试会归类到和功能名称匹配的子文件夹中（例如
```
.finalrun/tests/<功能名称>/
```
）。
搜索和当前需求相关的功能文件夹。
- 如果存在相关功能文件夹： 检查文件夹内的YAML文件。
  - 如果已存在相关测试，计划更新现有文件。
  - 如果不存在相关测试，计划在此文件夹内新建
```
.yaml
```
    文件。
- 如果不存在相关功能文件夹： 计划新建功能文件夹（例如
```
.finalrun/tests/<新功能名称>/
```
  ）。
- 如果有多个功能文件夹可能相关： 停止操作。请用户确认哪个文件夹对应主要功能。
对
```
.finalrun/suites/
```
下的测试套件执行类似流程。套件文件在概念上应和功能文件夹匹配，通常为
```
.finalrun/suites/<功能名称>.yaml
```
。更新现有套件以包含新测试，或如果不存在相关套件则新建套件。

Step 4 — Propose Plan & Review

步骤4 — 提议计划与审核

Present the proposed testing modifications to the user for validation.

State explicitly if you are UPDATING or CREATING files.
List the exact target paths you intend to touch.
Detail the Setup & Idempotent Cleanup strategy (as described below) you intend to use.
Setup checklist: List every
```
${variables.*}
```
and
```
${secrets.*}
```
the tests will use, and confirm the matching entries you will add to
```
.finalrun/env/*.yaml
```
(secret rows as
```
${ENV_VAR}
```
only).
Effective app checklist: State which app identifier FinalRun should use for each env/platform affected by the change.
Inference checklist: State which app identifiers were inferred from the repo, which files they came from, and whether any user confirmation is still needed.

[!CAUTION]
Do NOT write final test/suite
.yaml
until the user explicitly approves the proposed plan and answers your questions.

向用户展示拟定的测试修改方案供校验。

明确说明你是要更新还是创建文件。
列出你打算修改的精确目标路径。
详细说明你打算使用的准备与幂等清理策略（如下文所述）。
准备检查清单： 列出测试将使用的所有
```
${variables.*}
```
和
```
${secrets.*}
```
，确认你将添加到
```
.finalrun/env/*.yaml
```
的对应条目（密钥行仅显示
```
${ENV_VAR}
```
）。
生效应用检查清单： 说明受变更影响的每个环境/平台下FinalRun应使用的应用标识。
推导检查清单： 说明哪些应用标识是从仓库推导而来、来源文件是哪些，以及是否还需要用户确认。

[!CAUTION]
在用户明确批准拟定的计划并回答你的问题之前，不要写入最终的测试/套件
.yaml
文件。

Step 5 — Generate FinalRun artifacts

步骤5 — 生成FinalRun产物

Once approved, generate or update tests and suites using strict FinalRun YAML syntax.

Variable and secret declarations: Whenever the tests reference
```
${variables.*}
```
or
```
${secrets.*}
```
, create or update the corresponding
```
.finalrun/env/*.yaml
```
files in the same change set (per user choice: all env files or a subset).

获得批准后，使用严格的FinalRun YAML语法生成或更新测试与套件。

变量与密钥声明： 只要测试引用了
```
${variables.*}
```
或
```
${secrets.*}
```
，就在同一变更集中创建或更新对应的
```
.finalrun/env/*.yaml
```
文件（根据用户选择：更新所有环境文件或部分文件）。

Step 6 — Validation

步骤6 — 校验

Source of truth: run finalrun check
(with

--suite

or the right selectors and

--env

when multiple env files exist). That command validates the workspace, resolves bindings, and surfaces missing env vars or unknown keys.

Do not rely on ad-hoc greps alone for binding correctness; use
```
finalrun check
```
outcomes as the acceptance bar.
For the full verify-and-fix loop after edits, follow Next steps at the end of this skill.

校验的唯一标准： 运行**

finalrun check

**（存在多个环境文件时搭配

--suite

或合适的选择器与

--env

参数）。该命令会校验工作区、解析绑定、提示缺失的环境变量或未知键。

不要仅依赖临时grep判断绑定正确性；将
```
finalrun check
```
的输出作为验收标准。
编辑后完整的校验修复流程，请遵循本技能末尾的后续步骤。

Technical Specifications: Testing

技术规范：测试部分

Setup & Idempotent Cleanup Rule

准备与幂等清理规则

[!IMPORTANT] EVERY Setup & Cleanup Flow MUST BE IDEMPOTENT. Before writing any setup steps, you must ensure the test can run successfully regardless of the prior state of the app. If a previous run changed data (added an item, enabled a setting), this setup flow MUST clean that up first.

Cleanup is NOT redundant. Even if the cleanup steps involve navigating to the same screens as the test flow, you MUST include them.

If the test validates...	The Setup & Cleanup Flow MUST...
Adding an item	Check if the item exists and Delete/Remove it first.
Deleting an item	Check if the item exists and Add/Create it first if missing.
Enabling a toggle	Disable the toggle first if it's already on.
Moving/Reordering	Ensure the list is in a known default state first.

[!IMPORTANT] 所有准备与清理流程必须是幂等的。 编写任何准备步骤之前，你必须确保无论应用的之前状态如何，测试都能成功运行。如果上一次运行修改了数据（添加了条目、启用了某个设置），该准备流程必须先清理这些变更。

清理不是冗余操作。 即使清理步骤需要导航到和测试流程相同的页面，你也必须包含这些步骤。

如果测试校验...	准备与清理流程必须...
添加条目	检查条目是否存在，先删除/移除该条目。
删除条目	检查条目是否存在，如果缺失先添加/创建该条目。
启用开关	如果开关已经开启，先禁用该开关。
移动/重新排序	先确保列表处于已知的默认状态。

Writing Good Test Flows

编写优质测试流程

Be specific: Reference actual UI labels and recognizable controls (e.g. Settings screen, Settings button).
Name visible controls clearly: Use plain language like Save button and Home screen.
Variables: Use syntax like "Type
```
${variables.search_term}
```
into the search field".
Idempotency is the priority: Assume the test has already run and failed once; the setup flow must fix it.

明确具体： 引用真实的UI标签和可识别的控件（例如设置页面、设置按钮）。
清晰命名可见控件： 使用简单易懂的表述，例如保存按钮、首页。
变量： 使用类似"在搜索框中输入
```
${variables.search_term}
```
"的语法。
幂等性是首要要求： 假设测试已经运行过一次且失败，准备流程必须修复状态问题。

Strict YAML Formatting

严格YAML格式要求

Use exact 2-space indentation depth.
Quote string values if they contain special characters (e.g.,
```
:
```
,
```
#
```
).
Use flat lists for lists only (no nested complex lists unless strictly required).
Do NOT wrap the file content inside markdown code fences when saving the file to disk. The file extension should be
```
.yaml
```
.

使用精确的2空格缩进。
如果字符串值包含特殊字符（例如
```
:
```
、
```
#
```
），请为字符串值添加引号。
仅对列表使用扁平化结构（除非严格必要，否则不要嵌套复杂列表）。
保存文件到磁盘时，不要将文件内容包裹在markdown代码块中。文件扩展名应为
```
.yaml
```
。

Test File Template (

.finalrun/tests/<feature-name>/<file>.yaml

)

测试文件模板（

.finalrun/tests/<功能名称>/<文件>.yaml

）

Every test specification file must strictly follow this exact schema:

yaml

name: <snake_case_name>
description: <One or two sentences describing what the test validates.>
setup:
  - <string>
steps:
  - <string>
assertions:
  - <string>

Instruction Guidelines for the specific keys:

name: Short unique identifier.
description: High level summary of the user journey.
setup: Actionable steps to guarantee a clean starting state, honoring the Idempotency rule. Ensure you navigate and perform the cleanup visually if prior failure polluted the app state.
steps: Chronological list of user interactions. Name the target screen, button, field, or control directly in each step.
assertions: Specific boolean checks of UI labels, elements, or visibility to prove test passage.

每个测试规范文件必须严格遵循以下Schema：

yaml

name: <snake_case格式的名称>
description: <一两句话说明测试校验的内容。>
setup:
  - <字符串>
steps:
  - <字符串>
assertions:
  - <字符串>

特定键的编写指南：

name: 简短的唯一标识符。
description: 用户旅程的高层级概述。
setup: 保证初始状态干净的可执行步骤，遵守幂等规则。如果之前的失败污染了应用状态，确保你通过可视化导航执行清理操作。
steps: 按时间顺序排列的用户交互列表。每个步骤中直接写明目标页面、按钮、字段或控件。
assertions: 针对UI标签、元素或可见性的具体布尔校验，用于证明测试通过。

Suite File Template (

.finalrun/suites/<feature-name>.yaml

)

套件文件模板（

.finalrun/suites/<功能名称>.yaml

）

Suites group test specs logically. If you define tests for a feature, there must be a suite encompassing them. Every suite file must strictly follow this exact schema:

yaml

name: <feature_suite_name>
description: <One or two sentences describes what the suite covers.>
tests:
  - .finalrun/tests/<feature-name>/<file>.yaml

套件用于按逻辑分组测试规范。如果你为某个功能编写了测试，必须有一个包含这些测试的套件。每个套件文件必须严格遵循以下Schema：

yaml

name: <功能套件名称>
description: <一两句话说明套件覆盖的内容。>
tests:
  - .finalrun/tests/<功能名称>/<文件>.yaml

Next steps

后续步骤

After creating or updating test specs, suite manifests, and (when needed) env files:

Run
finalrun check
on the same scope you changed. Use --suite <path>
under
```
.finalrun/suites
```
when validating a suite, or pass positional selectors (YAML paths, directories, or globs under
```
.finalrun/tests/
```
). Pass --env <name>
when the workspace has multiple
```
.finalrun/env/*.yaml
```
files and the CLI requires a choice, or when validating a specific named profile.
If
finalrun check
fails, treat the command output as the source of truth. Typical fixes: missing or mistyped variables.*
/ secrets.*
in
```
.finalrun/env/<env>.yaml
```
(one file per environment name, e.g.
```
dev.yaml
```
, not named after a shell variable), references in specs that do not match declared keys, or required secrets.*
values not exported in the shell/CI environment (placeholders in YAML must stay as
```
"${SHELL_ENV_VAR}"
```
; never commit plaintext secrets).
Apply this skill’s rules when editing env files: follow Variables & secrets and Step 2 — Environment bindings (reuse keys, add placeholders for secrets, align keys across env files if the user wants consistency).
Re-run
finalrun check
until it succeeds. If errors point at spec structure or paths, fix those YAML files and check again.

finalrun

is not on

PATH

, resolve the install or invoke it by absolute path before relying on check output.

创建或更新测试规范、套件清单，以及（必要时）环境文件后：

在你修改的同一范围内运行
finalrun check
。校验套件时使用
```
.finalrun/suites
```
下的**
```
--suite <路径>
```
，或传入位置选择器**（
```
.finalrun/tests/
```
下的YAML路径、目录或通配符）。如果工作区存在多个
```
.finalrun/env/*.yaml
```
文件且CLI要求选择，或者要校验特定命名的配置文件时，传入**
```
--env <名称>
```
**。
如果
finalrun check
运行失败，将命令输出作为唯一判断标准。典型修复方案：
```
.finalrun/env/<env>.yaml
```
中缺失或拼写错误的**
```
variables.*
```
** / secrets.*
（每个环境对应一个文件，例如
```
dev.yaml
```
，不要以shell变量命名）、规范中的引用和声明的键不匹配、或者shell/CI环境中没有导出必填的**
```
secrets.*
```
**值（YAML中的占位符必须保持为
```
"${SHELL_ENV_VAR}"
```
；绝对不要提交明文密钥）。
编辑环境文件时应用本技能的规则：遵循变量与密钥和步骤2 — 环境绑定的要求（复用键、添加密钥占位符、如果用户需要一致性则对齐所有环境文件的键）。
重新运行
finalrun check
直到运行成功。如果错误指向规范结构或路径，修复对应的YAML文件后再次检查。

如果

finalrun

不在

PATH

中，先解决安装问题或通过绝对路径调用，再使用check的输出作为判断标准。

finalrun-generate-test

Original

Translation

FinalRun Test and Suite Generator

FinalRun 测试与套件生成器

Core Principles

核心原则

Workflow Steps

工作流步骤

Step 1 — Deep Dive & Analysis

步骤1 — 深度调研与分析

Step 1A — Infer app identity (name, bundle ID, package name) from the repo

步骤1A — 从仓库推导应用标识（名称、bundle ID、package name）

Step 2 — Environment profiles (required when tests use
`${variables.}`
or
`${secrets.}`
, or when app identity differs by environment)

步骤2 — 环境配置文件（当测试使用
`${variables.}`
或
`${secrets.}`
，或应用标识随环境变化时必填）

Step 3 — Planning & Folder Discovery

步骤3 — 规划与文件夹探查

Step 4 — Propose Plan & Review

步骤4 — 提议计划与审核

Step 5 — Generate FinalRun artifacts

步骤5 — 生成FinalRun产物

Step 6 — Validation

步骤6 — 校验

Technical Specifications: Testing

技术规范：测试部分

Setup & Idempotent Cleanup Rule

准备与幂等清理规则

Writing Good Test Flows

编写优质测试流程

Strict YAML Formatting

严格YAML格式要求

Test File Template (
`.finalrun/tests/<feature-name>/<file>.yaml`
)

测试文件模板（
`.finalrun/tests/<功能名称>/<文件>.yaml`
）

Suite File Template (
`.finalrun/suites/<feature-name>.yaml`
)

套件文件模板（
`.finalrun/suites/<功能名称>.yaml`
）

Next steps

后续步骤

finalrun-generate-test

Original

Translation

FinalRun Test and Suite Generator

FinalRun 测试与套件生成器

Core Principles

核心原则

Workflow Steps

工作流步骤

Step 1 — Deep Dive & Analysis

步骤1 — 深度调研与分析

Step 1A — Infer app identity (name, bundle ID, package name) from the repo

步骤1A — 从仓库推导应用标识（名称、bundle ID、package name）

Step 2 — Environment profiles (required when tests use ${variables.*} or ${secrets.*}, or when app identity differs by environment)

步骤2 — 环境配置文件（当测试使用${variables.*}或${secrets.*}，或应用标识随环境变化时必填）

Step 3 — Planning & Folder Discovery

步骤3 — 规划与文件夹探查

Step 4 — Propose Plan & Review

步骤4 — 提议计划与审核

Step 5 — Generate FinalRun artifacts

步骤5 — 生成FinalRun产物

Step 6 — Validation

步骤6 — 校验

Technical Specifications: Testing

技术规范：测试部分

Setup & Idempotent Cleanup Rule

准备与幂等清理规则

Writing Good Test Flows

编写优质测试流程

Strict YAML Formatting

严格YAML格式要求

Test File Template (.finalrun/tests/<feature-name>/<file>.yaml)

测试文件模板（.finalrun/tests/<功能名称>/<文件>.yaml）

Suite File Template (.finalrun/suites/<feature-name>.yaml)

套件文件模板（.finalrun/suites/<功能名称>.yaml）

Next steps

后续步骤

Step 2 — Environment profiles (required when tests use
`${variables.}`
or
`${secrets.}`
, or when app identity differs by environment)

步骤2 — 环境配置文件（当测试使用
`${variables.}`
或
`${secrets.}`
，或应用标识随环境变化时必填）

Test File Template (
`.finalrun/tests/<feature-name>/<file>.yaml`
)

测试文件模板（
`.finalrun/tests/<功能名称>/<文件>.yaml`
）

Suite File Template (
`.finalrun/suites/<feature-name>.yaml`
)

套件文件模板（
`.finalrun/suites/<功能名称>.yaml`
）