generate-finalrun-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
```
  当作应用包名。
- 不要自动从每个构建变种中推断环境名称；
```
free
```
  /
```
paid
```
  和
```
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.*
```
  配置。
- 将
```
secrets.*
```
  添加为
```
"${ENV_VAR}"
```
  占位符（选择稳定的
```
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标签和可识别的控件（例如设置页面、设置按钮）。
清晰命名可见控件： 使用通俗易懂的表述，例如保存按钮、首页。
变量： 使用类似"Type
```
${variables.search_term}
```
into the search field"的语法。
幂等性是首要要求： 假设测试已经运行过一次且失败了，设置流程必须修复这个问题。

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_name>
description: <One or two sentences describing what the test validates.>
setup:
  - <string>
steps:
  - <string>
assertions:
  - <string>

特定键的编写指南：

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: <feature_suite_name>
description: <One or two sentences describes what the suite covers.>
tests:
  - .finalrun/tests/<feature-name>/<file>.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
在你修改的相同范围内。使用**
```
--suite <path>
```
** 校验
```
.finalrun/suites
```
下的套件，或者传入位置选择器（
```
.finalrun/tests/
```
下的YAML路径、目录或通配符）。当工作区有多个
```
.finalrun/env/*.yaml
```
文件且CLI需要选择，或者要校验特定命名的配置文件时，传入**
```
--env <name>
```
** 参数。
如果
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的输出。

generate-finalrun-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

后续步骤

generate-finalrun-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`
）