Back to Details

kelly-app-skill-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Kelly App Skill Creator

Kelly App 技能生成器

Turn a recurring human-and-Agent operation into a Busabase-backed skill with a canonical Hono project whose normal delivery target is Busabase AirApp. Own the product workflow and the App-in-Skill artifact contract; delegate Busabase resource implementation and AirApp deployment mechanics.
将重复性的人工与Agent操作转化为基于Busabase的技能，采用标准Hono项目，默认交付目标为Busabase AirApp。负责产品工作流与App-in-Skill制品合约；将Busabase资源实现与AirApp部署机制委托给其他组件处理。

Ownership Boundary

职责边界

This skill is a taste layer over a format layer, and the split is what keeps both honest:
  • $busabase-app-creator
    (also published as 
    busabase-skill-creator
    and 
    busabase-template-creator
    — one skill, three names) owns everything that makes the artifact valid: the skill/template/package format, AirApp runtime language, framework, server shape, dependency and SDK constraints, security boundaries, validation, sync, and deployment mechanics. Its own contract says it is "format and correctness, not taste" — it deliberately carries no visual opinions, so this layer can.
  • This skill owns everything that makes the artifact Kelly's: product behavior, information architecture, visible UI, layout, interaction patterns, responsive behavior, accessibility, Help & Settings, hash routing, and visual acceptance for every generated app. Creating the underlying artifact is that skill's package-first route (§ "Two Ways In" there) with this skill's UI contract applied on top.
  • $kelly-app-skill-creator-tests
    owns repository-level conformance, process, responsive browser, OSS Busabase, Cloud OAuth, persistence, and AirApp parity tests for the generated app.
  • Do not delegate Kelly UI decisions to 
    $busabase-app-creator
    , and do not let a runtime scaffold replace or weaken this skill's desktop or phone shell.
  • Do not restate AirApp runtime limits here. When a runtime rule affects UI implementation, satisfy it inside the UI contract rather than creating a competing runtime contract.
本技能是格式层之上的体验层，这种分工确保两者各司其职：
  • $busabase-app-creator
    （也以
    busabase-skill-creator
    和
    busabase-template-creator
    发布——一个技能，三个名称）负责确保制品合法有效的所有事项：技能/模板/包格式、AirApp运行时语言、框架、服务端结构、依赖与SDK约束、安全边界、验证、同步及部署机制。其自身合约明确为「格式与正确性，而非体验」——刻意不包含任何视觉偏好，以便本层可专注体验设计。
  • 本技能负责确保制品具备Kelly特性的所有事项：产品行为、信息架构、可见UI、布局、交互模式、响应式表现、可访问性、帮助与设置、哈希路由，以及每个生成应用的视觉验收标准。创建底层制品时采用该技能的「包优先」路径（详见其文档中的「两种接入方式」章节），并在此基础上应用本技能的UI合约。
  • $kelly-app-skill-creator-tests
    负责生成应用的仓库级一致性测试、流程测试、响应式浏览器测试、开源Busabase测试、云OAuth测试、持久化测试及AirApp一致性测试。
  • 请勿将Kelly UI决策委托给
    $busabase-app-creator
    ，也不要让运行时脚手架替代或弱化本技能的桌面端/移动端外壳。
  • 请勿在此重述AirApp运行时限制。当运行时规则影响UI实现时，在UI合约内满足该规则，而非创建竞争性的运行时合约。

Mandatory Dependencies

强制依赖

Before creating or changing an app:
  1. Read and follow 
    $busabase
    for connection, target Space, node discovery, ChangeRequests, review, merge, and trusted mutations.
  2. Read and follow 
    $busabase-app-creator
    for resource modeling, native Views, Vault boundaries, AirApp constraints, scaffolding, validation, sync, and deployment. Creating an app-skill takes its package-first route — that skill's own guidance already routes a skill there, because a skill carrying an app is a template. The artifact is authored as a template package and verified by installing it; this skill's UI contract governs what the app inside it looks like.
If a dependency is unavailable, preserve this skill's local artifact and product contracts, stop before the unavailable Busabase operation, and report the exact missing dependency. Do not invent a second data backend.
Before declaring a generated app complete, read and follow 
$kelly-app-skill-creator-tests
. Keep app-owned unit tests in 
<app-root>/test/
and delegate shared harness, external Busabase, OAuth, responsive browser, and AirApp parity acceptance to that testing skill. If it is unavailable, run the app's deterministic local checks and report the missing conformance suites rather than claiming full completion.
创建或修改应用前：
  1. 阅读并遵循
    $busabase
    的规范，处理连接、目标Space、节点发现、变更请求、审核、合并及可信变更。
  2. 阅读并遵循
    $busabase-app-creator
    的规范，处理资源建模、原生Views、Vault边界、AirApp约束、脚手架、验证、同步及部署。创建应用技能需采用其包优先路径——该技能自身指引已将技能路由至此处，因为承载应用的技能本质是模板。制品以模板包形式编写，并通过安装进行验证；本技能的UI合约管控其中应用的外观。
若某依赖不可用，请保留本技能的本地制品与产品合约，在执行到依赖Busabase的操作前停止，并报告具体缺失的依赖。请勿自行搭建第二套数据后端。
在宣布生成应用完成前，阅读并遵循
$kelly-app-skill-creator-tests
的规范。将应用自有单元测试放在
<app-root>/test/
目录下，将共享测试 harness、外部Busabase测试、OAuth测试、响应式浏览器测试及AirApp一致性验收测试委托给该测试技能。若该技能不可用，请运行应用的确定性本地检查，并报告缺失的一致性套件，而非声称完全完成。

Reference Map

参考映射表

Read the two UI references completely for every app creation or UI change. Read the other selected references completely before acting:
NeedReference
Busabase SDK, node selection, config, state, locks, readiness, secrets
references/busabase-data-contract.md
Runtime readiness, product onboarding, setup UX, reconfiguration
references/setup-onboarding.md
Human verdicts, Agent revision, claims, external execution, rehearsal, recovery
references/review-and-execution-contract.md
Product shape selection
references/app-types.md
Research/Plan/Action/Retrospective patterns
references/workflow-patterns.md
Attention UI, review actions, routing, settings, i18n
references/ui-workflow-patterns.md
Desktop and mobile shell implementation
references/mobile-shell-layout.md
Large zero-build frontend module splits
references/frontend-modules.md
Large stylesheet splits with cascade layers
references/css-modules.md
Requested screenshots or demo recordings
references/demo-recording.md
每次创建应用或修改UI时，需完整阅读两份UI参考文档。执行操作前，需完整阅读其他选定的参考文档：
需求参考文档
Busabase SDK、节点选择、配置、状态、锁、就绪状态、密钥
references/busabase-data-contract.md
运行时就绪、产品引导、配置UX、重新配置
references/setup-onboarding.md
人工裁决、Agent修订、声明、外部执行、预演、恢复
references/review-and-execution-contract.md
产品形态选择
references/app-types.md
研究/规划/执行/回顾模式
references/workflow-patterns.md
注意力UI、审核操作、路由、设置、国际化
references/ui-workflow-patterns.md
桌面端与移动端外壳实现
references/mobile-shell-layout.md
大型零构建前端模块拆分
references/frontend-modules.md
采用层级 cascade 的大型样式表拆分
references/css-modules.md
要求的截图或演示录制
references/demo-recording.md

App-in-Skill Contract

App-in-Skill 合约

  • Every generated skill includes a complete canonical AirApp project with its own 
    package.json
    , lockfile, server entry, browser files, and checks. It lives at 
    <skill-root>/content/<name>-app/
     — the busabase template layout, which is simply what an app-skill looks like: the same directory is a skill, a template, and an installable package, with no second copy of anything. kelly-email is the fleet's reference for this shape.
  • A skill still holding its project at 
    <skill-root>/app/
    predates that layout and is awaiting migration — the fleet is being converted. Maintain such a skill where it is; do not relocate one as a side effect of unrelated work, because the move also rewrites harness paths, root scripts, and the scripts' own relative imports, and each one needs its suite re-run. Migration is its own task, not a by-product.
  • Either root must remain locally runnable with 
    pnpm --dir <that-root> dev
    , but do not start it unless the user explicitly asks for local preview or local debugging. The rest of this document calls whichever one applies the app root.
  • When the user asks to start, open, or launch an existing local app, open the bare production URL without 
    ?demo=1
    or any other Demo selector. The normal launch path must exercise the Busabase connection and OAuth gate. Demo is an explicit opt-in for a requested demo, screenshot, recording, or a separate UI acceptance pass; never present its URL as the normally launched app.
  • Delegate the runtime language, framework, dependency, SDK bundle, server, Nodepod, validation, and deployable-file rules to 
    $busabase-app-creator
    . Never restate or override those rules here or in a generated domain skill.
  • Treat the committed local source as canonical. Build and sync the AirApp from that source; never leave a remote-only AirApp edit without back-porting it.
  • Use the same UI, routes, domain logic, validation, and Busabase resource map locally and in AirApp. Isolate only the runtime bootstrap/transport adapter.
  • Use 
    busabase-sdk
    as the application data boundary. Persistent domain config, workflow state, user decisions, locks/claims, and domain records belong in Busabase, not local JSON, 
    app/.data/
    , SQLite, or browser storage.
  • Permit environment variables only for connection bootstrap such as 
    BUSABASE_BASE_URL
    , 
    BUSABASE_API_KEY
    , and 
    BUSABASE_SPACE_ID
    . They are not a parallel domain-config system.
  • Never expose an API key or Vault value to browser code, UI state, logs, demos, or screenshots. Secret access stays in the Hono server or trusted AirApp execution boundary.
  • Keep external side effects outside the AirApp. The AirApp may submit a ChangeRequest-producing decision or proposal; only a trusted Agent or Workflow may use Vault-backed integrations to send, publish, delete, charge, transfer, or mutate an external system after its own required authorization.
  • Use local storage only for disposable browser presentation state when it cannot affect behavior, authorization, workflow, or cross-device expectations. Store operator preferences in Busabase when they should follow the operator.
  • Do not offer provider choice. Local development connects to local, Cloud, or self-hosted Busabase through the same SDK contract.
  • 每个生成的技能都包含完整的标准AirApp项目，拥有独立的
    package.json
    、锁文件、服务端入口、浏览器文件及检查机制。项目存放于
    <skill-root>/content/<name>-app/
    ——即Busabase模板布局，也是应用技能的标准结构：同一目录同时作为技能、模板及可安装包，无任何重复内容。kelly-email是该结构的 fleet 参考示例。
  • 项目仍存放在
    <skill-root>/app/
    的技能属于旧版布局，待迁移——当前正在对整个fleet进行转换。此类技能需保持原有位置；请勿在无关工作中顺带迁移，因为迁移还需重写harness路径、根脚本及脚本自身的相对导入，且每个技能都需重新运行测试套件。迁移是独立任务，而非附属操作。
  • 无论采用哪种根目录，都需支持通过
    pnpm --dir <that-root> dev
    本地运行，但仅在用户明确请求本地预览或本地调试时才启动。本文档后续将适用的根目录称为应用根目录。
  • 当用户要求启动、打开或运行现有本地应用时，打开纯生产环境URL，不带
    ?demo=1
    或任何其他Demo参数。常规启动路径必须验证Busabase连接与OAuth网关。Demo仅在明确请求演示、截图、录制或单独UI验收时启用；切勿将其URL作为常规启动应用的地址。
  • 将运行时语言、框架、依赖、SDK包、服务端、Nodepod、验证及可部署文件规则委托给
    $busabase-app-creator
    。请勿在此或生成的领域技能中重述或覆盖这些规则。
  • 将提交的本地源码视为权威版本。基于该源码构建并同步AirApp；切勿留下仅存在于远程的AirApp编辑内容而不反向同步至本地。
  • 本地与AirApp环境使用相同的UI、路由、领域逻辑、验证及Busabase资源映射。仅隔离运行时引导/传输适配器。
  • 使用
    busabase-sdk
    作为应用数据边界。持久化领域配置、工作流状态、用户决策、锁/声明及领域记录需存储在Busabase中，而非本地JSON、
    app/.data/
    、SQLite或浏览器存储。
  • 仅允许环境变量用于连接引导，如
    BUSABASE_BASE_URL
    、
    BUSABASE_API_KEY
    及
    BUSABASE_SPACE_ID
    。它们并非并行的领域配置系统。
  • 切勿向浏览器代码、UI状态、日志、演示或截图暴露API密钥或Vault值。密钥访问需限制在Hono服务端或可信AirApp执行边界内。
  • 将外部副作用置于AirApp之外。AirApp可提交生成变更请求的决策或提案；仅可信Agent或工作流可在完成自身所需授权后，使用Vault支持的集成来发送、发布、删除、收费、传输或变更外部系统。
  • 仅当浏览器展示状态不会影响行为、授权、工作流或跨设备预期时，才可使用本地存储存放此类临时状态。需跟随操作员的偏好设置需存储在Busabase中。
  • 不提供提供商选择。本地开发通过同一SDK合约连接至本地、云端或自托管的Busabase。

Default Delivery Mode

默认交付模式

Use 
airapp-first
unless the user explicitly asks for 
pnpm dev
, a local URL, local preview, or local debugging.
  • In 
    airapp-first
    , generate and keep the app root as the canonical source, run its deterministic checks, and submit that same reviewed tree as a Busabase AirApp ChangeRequest. Do not start a standalone local server merely because the project supports one.
  • After the named AirApp CR is merged with explicit authority, Run the AirApp in the selected Busabase and perform product, desktop, phone, ambient-session, resource, and real-data acceptance there. Return the exact clickable AirApp URL; do not substitute a localhost URL.
  • Use 
    local-preview
    only after an explicit user request. Then start 
    pnpm dev
    , apply the Connection UX Contract, report the bare non-Demo local URL as the primary user-facing URL, and state plainly that the process is standalone and has not uploaded or deployed an AirApp. When acceptance also requires Demo, exercise it as a separate validation route rather than the launch default.
  • A Folder or Base created in Busabase does not prove that the AirApp exists. Confirm an actual 
    airapp
    node and its merged version before saying it was uploaded, deployed, or is running in Busabase.
  • Local preview never becomes a second implementation. Whether or not it is started, the same app-root tree remains the only source submitted to AirApp.
除非用户明确请求
pnpm dev
、本地URL、本地预览或本地调试，否则默认使用
airapp-first
模式。
  • 在
    airapp-first
    模式下，生成并保留应用根目录作为权威源码，运行其确定性检查，并将同一已审核代码树作为Busabase AirApp变更请求提交。切勿仅因项目支持本地运行就启动独立本地服务。
  • 当指定的AirApp变更请求获得明确授权并合并后，在选定的Busabase中运行AirApp，并在该环境中完成产品、桌面端、移动端、会话环境、资源及真实数据验收。返回可直接点击的AirApp URL；请勿替换为localhost URL。
  • 仅在用户明确请求后使用
    local-preview
    模式。此时启动
    pnpm dev
    ，应用连接UX合约，将纯非Demo本地URL作为主要用户可见URL，并明确说明该进程为独立运行，尚未上传或部署AirApp。当验收同时需要Demo时，将其作为单独的验证流程，而非默认启动方式。
  • 在Busabase中创建的文件夹或Base并不代表AirApp已存在。在声称AirApp已上传、部署或正在Busabase中运行前，需确认实际存在
    airapp
    节点及其合并版本。
  • 本地预览永远不会成为第二套实现。无论是否启动本地服务，同一应用根目录代码树始终是提交至AirApp的唯一源码。

Connection UX Contract

连接UX合约

When 
local-preview
was explicitly requested, every standalone App-in-Skill must be usable without a CLI login or pasted API key. Only in that standalone context, when no connection exists, show one focused setup screen with:
  • a selected 
    Busabase Cloud
    option using the canonical Cloud URL;
  • a 
    Custom server
    option that reveals one URL field for self-hosted or enterprise Busabase;
  • one primary 
    Connect Busabase
    action that starts browser OAuth;
  • one secondary, visually quieter Demo action when the app has a deterministic Demo provider.
Do not ask for an API key, device code, terminal command, provider selection, or secret-storage choice. Cloud/custom is a hosting target choice, not a data provider choice. Preserve the chosen server only as connection bootstrap; all product configuration still comes from Busabase nodes through 
busabase-sdk
.
After OAuth returns, distinguish successful authentication, Space targeting, and resource readiness. Call Busabase auth verification without a Space header to obtain every accessible Space. When Cloud or an enterprise host returns more than one, show a native Space selector with names and safe ids; do not inspect, initialize, or repair app resources until the operator confirms one. When it returns exactly one, select it automatically. Open-source Busabase reports its single 
local
Space and never shows this selector.
Persist only the validated Space id as local connection bootstrap, separately from domain configuration, and inject it as 
x-busabase-space
on every proxied SDK request. Changing server or signing out clears the selection. Show the selected Space name/id on later setup and Help & Settings screens. An expired or revoked session returns to the connection screen with a concise retry message. Demo never impersonates a successful connection and remains explicitly labeled read-only.
Use the canonical 
createBusabaseAirAppLocalGateway()
exported by 
busabase-sdk/airapp-node
; do not copy PKCE, token refresh, Space persistence, or proxy code into each 
server.js
. Browser-provided 
x-busabase-space
is untrusted and must never override the gateway's validated server-side choice. Treat 
SPACE_SELECTION_REQUIRED
and 
SPACE_NOT_ALLOWED
as stable reasons; never parse a human error sentence to decide which setup screen to render.
当明确请求
local-preview
时，每个独立的App-in-Skill必须无需CLI登录或粘贴API密钥即可使用。仅在该独立场景下，当无连接时，展示一个聚焦的配置界面，包含：
  • 选中的
    Busabase Cloud
    选项，使用标准Cloud URL；
  • 自定义服务器
    选项，展开后显示一个用于自托管或企业级Busabase的URL输入框；
  • 一个主操作按钮
    连接Busabase
    ，启动浏览器OAuth流程；
  • 一个次要、视觉上更低调的Demo按钮（仅当应用具备确定性Demo提供商时显示）。
请勿要求输入API密钥、设备代码、终端命令、提供商选择或密钥存储选项。云端/自定义是托管目标选择，而非数据提供商选择。仅将选定服务器作为连接引导保存；所有产品配置仍通过
busabase-sdk
从Busabase节点获取。
OAuth返回后，区分成功认证、Space定位及资源就绪状态。调用不带Space头的Busabase认证验证接口，获取所有可访问的Space。当云端或企业级主机返回多个Space时，显示原生Space选择器，包含名称及安全ID；在操作员确认前，请勿检查、初始化或修复应用资源。当仅返回一个Space时，自动选中。开源Busabase仅报告单个
local
Space，永不显示该选择器。
仅将已验证的Space ID作为本地连接引导保存，与领域配置分离，并在每个代理的SDK请求中注入
x-busabase-space
头。更改服务器或登出将清除该选择。在后续配置及帮助与设置界面显示选定的Space名称/ID。会话过期或撤销时，返回连接界面并显示简洁的重试提示。Demo永远不会伪装成成功连接，始终明确标记为只读。
使用
busabase-sdk/airapp-node
导出的标准
createBusabaseAirAppLocalGateway()
；请勿将PKCE、令牌刷新、Space持久化或代理代码复制到每个
server.js
中。浏览器提供的
x-busabase-space
不可信，绝不能覆盖网关的服务端验证选择。将
SPACE_SELECTION_REQUIRED
和
SPACE_NOT_ALLOWED
视为稳定错误原因；切勿解析人工错误语句来决定显示哪个配置界面。

"Standalone" is a fact the host states, not one the app infers

"独立运行"是宿主声明的事实，而非应用推断的结果

Copy 
assets/runtime-detection/
— do not re-derive it. Three files, and every generated App gets all three:
AssetGoes toRole
runtime.js
app/js/runtime.js
the only module that answers "where am I"
server-route.js
into 
server.js
, beside 
/health
hands the injected fact to the browser
check-rules.mjs
into 
scripts/check.mjs
assertions		fails the build if the rule is broken
This is a copied asset rather than prose because prose did not hold: 65 generated Apps had each independently reinvented the same loopback-hostname test, and one App's own check script had gone as far as requiring it.
Busabase spawns the App's own process in every runtime it hosts and injects a non-empty 
BUSABASE_AIRAPP_RUNTIME
. Nobody else sets it, so its absence is the positive fact "standalone". 
server.js
must re-expose the result from 
describeBusabaseAirAppRuntime()
— the browser cannot read environment variables, and the SDK keeps renamed and future runtime values compatible.
Never derive this from the URL — not the hostname, not 
window.self !== window.top
, not a 
/api/airapp-preview/
path prefix. Every such test misfires in both directions. A Busabase-hosted App is served from 
localhost
on Desktop and OSS (
http://localhost:15419
), so "loopback ⇒ standalone" is wrong; and a standalone 
pnpm dev
is routinely reached over a LAN IP or a signed dev tunnel such as 
https://3111-t14e66e832aa5e6a.dev.budaapps.com
, so "not loopback ⇒ hosted" is wrong. The second direction is the damaging one: the App hides its own connect gate, calls 
/api/v1
with no credential, and reports an error the operator cannot act on.
Browser code probes 
__airapp/runtime
relatively (no leading slash — a hosted App can be served from a sub-path of Busabase's origin) and must verify the response is JSON, since a hosted origin's catch-all route can answer 
200
with an HTML shell.
runtime.js
resolves the probe with a top-level 
await
, so its two predicates stay synchronous for their call sites. When a module both re-exports one of them and calls it, use 
import
+ 
export
, never 
export { … } from "./runtime.js"
— a re-export does not bind the name locally, and the App dies at runtime with 
shouldUseLocalGateway is not defined
while every static check still passes.
Resolve three states, never two — 
hosted
, 
standalone
, 
unknown
— and let each decision fall to its own safe side when the runtime is undetermined:
DecisionSafe default when 
unknown
Why
Show the connect gateshow itAn unnecessary gate is closed by the operator; a missing one strands them.
Merge writes instead of raising a ChangeRequestdo not mergeA reviewable write can still be approved; one that auto-merged has already crossed the review boundary.
scripts/check.mjs
must fail on 
location.hostname
and iframe-nesting tests, and must assert the server exposes 
/__airapp/runtime
.
Apply 
references/setup-onboarding.md
after authentication. Infrastructure readiness and product onboarding are separate: a connected, materialized AirApp may still need operator context, policies, sources, thresholds, schedules, or approval rules before the workflow can act.
Never tell the operator to create Nodes/Bases, approve a list of unnamed ChangeRequests, or copy materialized ids into deployment config. For an approved lazy-provisioning blueprint, show one 
Initialize workspace
action only after Space selection and concise progress while 
$busabase-app-creator
submits the exact declared structure as an idempotent ChangeRequest in that Space. Continue automatically when it materializes. If the viewer lacks write permission, show the one pending CR id or the exact permission needed; the operator reviews that request, not a manual schema recipe.
This screen must fit the same phone contract as the main app: one-column server choices and full-width primary action at 390px and 360px, no horizontal overflow, and no terminal instructions. A deployed AirApp uses the ambient Busabase session and must not show the local OAuth gate, call 
/auth/status
or 
/auth/start
, or navigate to a Busabase OAuth endpoint.
Delegate PKCE, callback validation, owner-only local credential registration, refresh/revoke behavior, proxy injection, and AirApp ambient-session rules to 
$busabase-app-creator
. Browser JavaScript must never receive an OAuth access token, refresh token, PKCE verifier, or Vault value.
**复制
assets/runtime-detection/
目录——请勿自行推导。**包含三个文件，每个生成的应用都需全部复制：
资源存放路径作用
runtime.js
app/js/runtime.js
唯一回答「我在哪里运行」的模块
server-route.js
放入
server.js
，与
/health
路由同级		向浏览器传递注入的运行时事实
check-rules.mjs
放入
scripts/check.mjs
断言中		若规则被破坏则构建失败
这是复制资源而非文字说明，因为文字说明无法严格执行：已有65个生成应用各自独立实现了相同的环回主机名测试，甚至有一个应用的检查脚本要求必须进行该测试。
Busabase在其托管的每个运行时中启动应用自身进程，并注入非空的
BUSABASE_AIRAPP_RUNTIME
环境变量。其他方不会设置该变量，因此其缺失即为「独立运行」的明确标志。
server.js
必须重新暴露
describeBusabaseAirAppRuntime()
的结果——浏览器无法读取环境变量，且SDK会保持重命名及未来运行时值的兼容性。
切勿从URL推导运行时状态——无论是主机名、
window.self !== window.top
，还是
/api/airapp-preview/
路径前缀。此类测试都会双向误判。Busabase托管的应用在桌面端和开源环境中从
localhost
提供服务（
http://localhost:15419
），因此「环回⇒独立运行」的判断错误；而独立运行的
pnpm dev
通常通过LAN IP或签名开发隧道访问，如
https://3111-t14e66e832aa5e6a.dev.budaapps.com
，因此「非环回⇒托管运行」的判断也错误。第二种误判危害更大：应用隐藏自身连接网关，调用
/api/v1
时无凭据，导致操作员无法解决的错误。
浏览器代码需相对探测
__airapp/runtime
（无前置斜杠——托管应用可从Busabase源的子路径提供服务），且必须验证响应为JSON，因为托管源的兜底路由可能返回
200
状态码及HTML外壳。
runtime.js
通过**顶层
await
**解析探测请求，因此其两个断言对调用方保持同步。当模块同时重新导出并调用其中一个断言时，需使用
import
+ 
export
，切勿使用
export { … } from "./runtime.js"
——重新导出不会在本地绑定名称，会导致应用运行时出现
shouldUseLocalGateway is not defined
错误，而所有静态检查仍会通过。
需区分三种状态，而非两种——
托管
、
独立
、
未知
——当运行时状态不确定时，每个决策需采用安全默认值：
决策状态为
未知
时的安全默认值		原因
显示连接网关显示不必要的网关可由操作员关闭；缺失网关会导致操作员无法操作
合并写入而非发起变更请求不合并可审核的写入仍可获批准；自动合并的写入已越过审核边界
scripts/check.mjs
必须禁止
location.hostname
和iframe嵌套测试，并断言服务端暴露
/__airapp/runtime
路由。
认证完成后应用
references/setup-onboarding.md
规范。基础设施就绪与产品引导是分离的：已连接、实例化的AirApp可能仍需操作员提供上下文、策略、数据源、阈值、调度或审批规则，工作流才可执行操作。
切勿告知操作员创建节点/Base、批准未命名的变更请求列表，或复制实例化ID到部署配置中。对于已批准的延迟预置蓝图，仅在Space选择后显示一个
初始化工作区
操作，并在
$busabase-app-creator
提交明确声明的结构作为该Space中的幂等变更请求时显示简洁进度。变更请求实例化后自动继续。若查看者无写入权限，显示单个待处理变更请求ID或所需的具体权限；操作员需审核该请求，而非手动执行架构配置。
该界面需与主应用遵循相同的移动端合约：在390px和360px宽度下采用单列服务器选择及全宽主操作按钮，无水平溢出，无终端指令。已部署的AirApp使用Busabase的会话环境，不得显示本地OAuth网关、调用
/auth/status
或
/auth/start
，或导航至Busabase OAuth端点。
将PKCE、回调验证、仅所有者的本地凭证注册、刷新/撤销行为、代理注入及AirApp会话环境规则委托给
$busabase-app-creator
。浏览器JavaScript绝不能接收OAuth访问令牌、刷新令牌、PKCE验证器或Vault值。

Mandatory UI Contract

强制UI合约

Build a quiet operator tool, not a landing page or generic dashboard. Apply 
references/ui-workflow-patterns.md
and 
references/mobile-shell-layout.md
as hard implementation and acceptance gates.
  • Put the brand, human-attention summary, workflow navigation, and Help & Settings in a fixed desktop sidebar. Collapse it to an icon rail with a panel icon; keep the brand icon visible.
  • State the human task in action language and show the primary attention count above workflow navigation. Use stable row references for review queues.
  • For item-oriented work, use a desktop list/detail split such as 
    minmax(360px, 38%) minmax(0, 1fr)
    . Keep list and detail scrolling inside their panes.
  • Use native hash routes for meaningful views, selection, and Help & Settings so refresh and browser back/forward restore context.
  • At widths up to 720px, switch to a real phone shell: compact top bar, off-canvas sidebar with scrim, separate full-height list and detail panes, sticky back-to-list control, and sticky primary detail action when the workflow has one. Do not merely shrink the desktop UI.
  • Keep touch targets 36-44px, wrap long values, and prevent page-level horizontal overflow. Make Help & Settings a responsive modal and a full-screen panel on phones.
  • Verify at approximately 1280x820, 390x844, and 360x740. Exercise sidebar collapse/drawer, scrim, navigation, row selection, detail back, modal tabs, browser history, and overflow before handoff.
构建简洁的操作员工具，而非着陆页或通用仪表盘。将
references/ui-workflow-patterns.md
和
references/mobile-shell-layout.md
作为硬性实现与验收标准。
  • 将品牌标识、人工注意力摘要、工作流导航及帮助与设置放在固定的桌面端侧边栏中。可折叠为图标栏，保留面板图标；品牌图标需始终可见。
  • 使用动作语言陈述人工任务，并在工作流导航上方显示主要注意力计数。审核队列使用稳定行引用。
  • 对于面向项目的工作，采用桌面端列表/详情拆分布局，如
    minmax(360px, 38%) minmax(0, 1fr)
    。列表与详情区域各自独立滚动。
  • 使用原生哈希路由处理有意义的视图、选择及帮助与设置，以便刷新及浏览器前进/后退可恢复上下文。
  • 在宽度≤720px时，切换为真实移动端外壳：紧凑顶部栏、带遮罩的侧边抽屉、独立的全屏列表与详情面板、粘性返回列表控件，以及当工作流有主操作时的粘性详情主操作按钮。切勿仅缩放桌面端UI。
  • 保持触摸目标大小为36-44px，长值自动换行，防止页面级水平溢出。帮助与设置在移动端为响应式模态框及全屏面板。
  • 需在约1280x820、390x844及360x740分辨率下验证。移交前需测试侧边栏折叠/抽屉、遮罩、导航、行选择、详情返回、模态框标签、浏览器历史及溢出情况。

Busabase Resource Discipline

Busabase 资源规范

Select nodes for their native strengths instead of putting everything in one JSON blob:
  • use Folder and the Node tree for the app root, resource discovery, hierarchy, stable ownership, and navigation;
  • use Base for structured configuration, policies, workflow rows, review items, claims, metrics, and relations;
  • use Vault for secrets and secret references; surface readiness only;
  • use Doc for long-form instructions, research templates, playbooks, and editable narrative content;
  • use Drive and File for imports, attachments, exports, and large artifacts;
  • use native Views for routine table, gallery, kanban, calendar, and gantt work;
  • use AirApp for cross-resource synthesis, prioritization, guidance, and focused commands.
Create an explicit resource map before implementation. Record stable node ids or slugs, purpose, schema/version, read/write behavior, mutation path, and the screens or jobs that consume each resource. See 
references/busabase-data-contract.md
.
根据节点原生优势选择节点，而非将所有内容放入单个JSON blob：
  • 使用Folder和节点树作为应用根目录、资源发现、层级结构、稳定所有权及导航；
  • 使用Base存储结构化配置、策略、工作流行、审核项、声明、指标及关联关系；
  • 使用Vault存储密钥及密钥引用；仅显示就绪状态；
  • 使用Doc存储长格式说明、研究模板、操作手册及可编辑叙事内容；
  • 使用Drive和File存储导入文件、附件、导出文件及大型制品；
  • 使用原生Views处理常规表格、画廊、看板、日历及甘特图工作；
  • 使用AirApp处理跨资源合成、优先级排序、指引及聚焦命令。
实现前需创建明确的资源映射表。记录稳定节点ID或slug、用途、 schema/版本、读写行为、变更路径及使用每个资源的界面或任务。详见
references/busabase-data-contract.md
。

Product Loop

产品循环

Default to this four-stage operating loop.
默认采用以下四阶段运营循环。

Research

研究

Collect evidence on a schedule or on demand. Update an idempotent report for its period key and record source freshness, coverage, uncertainty, and findings.
按计划或按需收集证据。按周期键更新幂等报告，并记录数据源新鲜度、覆盖范围、不确定性及发现结果。

Plan

规划

Turn evidence into concrete, deduplicated work items linked back to their sources. Let humans opt out, block, reprioritize, reschedule, or request revision. Use an attention queue instead of forcing users to inspect every row.
将证据转化为具体、去重的工作项，并关联回其数据源。允许用户选择退出、阻止、重新排序、重新调度或请求修订。使用注意力队列，而非强制用户检查每个行项。

Action

执行

Claim eligible work atomically, create reviewable deliverables or ChangeRequests, record progress and failures, and keep consequential side effects behind the trusted approval/execution path.
原子化申领符合条件的工作，创建可审核的交付物或变更请求，记录进度与失败情况，并将重大副作用置于可信审批/执行流程之后。

Retrospective

回顾

Compare outcomes with original evidence and decisions. Propose improvements to prompts, skills, thresholds, sources, schedules, resource schemas, or UI as new Plan items; do not silently rewrite production rules from one outcome.
Not every stage needs its own screen. State where each stage happens or why it is intentionally omitted.
将结果与原始证据及决策进行对比。提出对提示词、技能、阈值、数据源、调度、资源schema或UI的改进建议，作为新的规划项；切勿因单次结果就静默重写生产规则。
并非每个阶段都需要独立界面。需说明每个阶段的执行位置或省略的原因。

Discovery

需求调研

Ask one question at a time. Learn enough to determine:
  • who operates the app, how often, and what outcome they own;
  • what triggers Research and defines one reporting period;
  • how evidence becomes a deduplicated Plan item;
  • what defaults to eligible and what humans may stop or revise;
  • what Action produces, where it is reviewed, and which effects are external;
  • what makes Retrospective useful;
  • which states require human attention;
  • which operations belong in native Views versus AirApp;
  • which existing Busabase Folder, Base, Doc, Drive, File, Skill, or Vault nodes should be reused and which must be proposed.
Do not ask the user to choose a provider, framework, schema mechanism, local config path, or secret-storage method.
一次提出一个问题。收集足够信息以确定：
  • 谁操作应用、操作频率及负责的结果；
  • 触发研究的条件及报告周期的定义；
  • 证据如何转化为去重的规划项；
  • 默认符合条件的规则及用户可停止或修订的内容；
  • 执行阶段产出的内容、审核位置及外部副作用；
  • 回顾阶段的有用指标；
  • 哪些状态需要人工关注；
  • 哪些操作属于原生Views，哪些属于AirApp；
  • 应重用哪些现有Busabase Folder、Base、Doc、Drive、File、Skill或Vault节点，哪些需要新建。
请勿要求用户选择提供商、框架、schema机制、本地配置路径或密钥存储方式。

Product Overlay

产品覆盖层

Before creation, produce this concise overlay for 
$busabase-app-creator
:
markdown
undefined
创建前，为
$busabase-app-creator
生成简洁的产品覆盖层：
markdown
undefined

Product Overlay

Product Overlay

User and outcome: ... App type: ...
Research: trigger, period key, evidence, freshness, idempotency Plan: issue/recommendation rule, traceability, default eligibility, opt-out Action: atomic claim, deliverable, review point, external side effects Retrospective: outcome signals, cadence, skill/process feedback
Human attention states: ... Agent responsibilities: ... Product onboarding: required operating context and completion/version rule Native Views needed: ... AirApp screens and focused actions: ... Busabase resource map: Folder/Node root, Bases, Docs, Drives/Files, Vault refs Delivery mode: airapp-first unless the user explicitly requested local-preview Guide copy in plain language: ... Explicit exclusions: ...

The overlay describes product behavior. `$busabase-app-creator` translates it
into the complete resource graph, capability matrix, security model, canonical
app-root scaffold, AirApp-compatible implementation, validation, sync,
and deployment.
User and outcome: ... App type: ...
Research: trigger, period key, evidence, freshness, idempotency Plan: issue/recommendation rule, traceability, default eligibility, opt-out Action: atomic claim, deliverable, review point, external side effects Retrospective: outcome signals, cadence, skill/process feedback
Human attention states: ... Agent responsibilities: ... Product onboarding: required operating context and completion/version rule Native Views needed: ... AirApp screens and focused actions: ... Busabase resource map: Folder/Node root, Bases, Docs, Drives/Files, Vault refs Delivery mode: airapp-first unless the user explicitly requested local-preview Guide copy in plain language: ... Explicit exclusions: ...

覆盖层描述产品行为。`$busabase-app-creator`将其转化为完整的资源图、能力矩阵、安全模型、标准应用根目录脚手架、兼容AirApp的实现、验证、同步及部署流程。

Creation Workflow

创建工作流

  1. Read the relevant references and inspect nearby App-based skills before choosing a structure.
  2. Establish the Busabase connection and explicit target Space.
  3. Discover the target Node tree and draft the resource map.
  4. Agree on the Product Overlay and let 
    $busabase-app-creator
    validate the technical blueprint.
  5. Have 
    $busabase-app-creator
    create or update the complete canonical project at the app root. Do not invent a second runtime layout in this skill.
  6. Implement one Busabase repository/service boundary over 
    busabase-sdk
    . Browser code calls Hono/AirApp routes; it does not hold credentials.
  7. Implement the runtime/product onboarding state and every review/execution lifecycle required by the overlay. Apply 
    references/setup-onboarding.md
    and 
    references/review-and-execution-contract.md
    ; do not invent local markers, locks, or a second provider.
  8. Keep setup, seed, refresh, migration, validation, and sync scripts as thin entrypoints over shared modules. Avoid Python, native binaries, subprocess orchestration, and filesystem-backed workflow state unless a domain adapter strictly requires them and AirApp compatibility is preserved.
  9. Run app-owned lint/typecheck/tests/build without starting a persistent local server, then use 
    $kelly-app-skill-creator-tests
    for repository-level contract, browser, OSS, and available Cloud suites. When the user explicitly selected 
    local-preview
    , also run 
    pnpm --dir <app-root> dev
    and complete local connection, workflow, recovery, desktop, and phone acceptance before continuing.
  10. By default, submit the same canonical source directly as a reviewable AirApp CR through 
    $busabase-app-creator
    ; return its clickable Busabase review URL and wait for the named merge authorization.
  11. After merge, Run the AirApp in Busabase and verify the same resource map, representative data, ambient session, main workflow, recovery states, and mandatory desktop/phone shell behavior. Report the canonical AirApp URL. Report a local URL only when 
    local-preview
    was explicitly requested.
  1. 选择结构前，阅读相关参考文档并检查同类基于App的技能。
  2. 建立Busabase连接并明确目标Space。
  3. 调研目标节点树并草拟资源映射表。
  4. 确认产品覆盖层，让
    $busabase-app-creator
    验证技术蓝图。
  5. 让
    $busabase-app-creator
    在应用根目录创建或更新完整的标准项目。请勿在本技能中自行设计第二套运行时布局。
  6. 在
    busabase-sdk
    之上实现一个Busabase仓库/服务边界。浏览器代码调用Hono/AirApp路由；不持有凭据。
  7. 实现运行时/产品引导状态及覆盖层要求的所有审核/执行生命周期。应用
    references/setup-onboarding.md
    和
    references/review-and-execution-contract.md
    规范；请勿自行设计本地标记、锁或第二套提供商。
  8. 将配置、初始化、刷新、迁移、验证及同步脚本作为共享模块的轻量级入口。除非领域适配器严格要求且能保持AirApp兼容性，否则避免使用Python、原生二进制文件、子进程编排及文件系统存储的工作流状态。
  9. 运行应用自有代码检查/类型检查/测试/构建，无需启动持久本地服务，然后使用
    $kelly-app-skill-creator-tests
    执行仓库级合约、浏览器、开源及可用云端测试套件。当用户明确选择
    local-preview
    时，还需运行
    pnpm --dir <app-root> dev
    ，并完成本地连接、工作流、恢复、桌面端及移动端验收后再继续。
  10. 默认情况下，通过
    $busabase-app-creator
    将同一标准源码直接作为可审核的AirApp变更请求提交；返回其可点击的Busabase审核URL，并等待明确的合并授权。
  11. 合并后，在Busabase中运行AirApp，并验证相同的资源映射表、代表性数据、会话环境、主工作流、恢复状态及强制桌面端/移动端外壳行为。报告标准AirApp URL。仅在明确请求
    local-preview
    时才报告本地URL。

Onboarding And Readiness

引导与就绪

Apply 
references/setup-onboarding.md
. The app must remain startable in an explicit local preview even when Busabase is not ready, and the hosted AirApp must render one setup/onboarding gate rather than silently switching to local or Demo data. Distinguish runtime readiness from product onboarding.
Runtime readiness states include:
  • missing connection bootstrap;
  • unauthenticated or unreachable Busabase;
  • ambiguous or inaccessible Space;
  • missing app Folder/resources;
  • schema migration needed;
  • missing Vault references;
  • ready.
Product onboarding separately covers the durable operating context, policies, sources, schedules, thresholds, and approval rules required by this workflow. Persist its fields and completion/version state in Busabase. Do not enable external reads or consequential actions whose product prerequisites are incomplete.
Declare an onboarding contract in the Product Overlay and machine-readable blueprint with a positive integer 
version
, explicit required fields, their owning Base/Doc resource keys, validation rules, and the actions each field unlocks. A product with no onboarding requirements must declare an explicit empty contract and rationale; omission is not equivalent to “none.” Persist 
onboarding_version
, completion state, and materialized completion time in the declared Busabase resource. A version mismatch enters 
needs_review
or 
migration_needed
, never 
complete
.
For missing or expired authentication, apply the Connection UX Contract above; do not replace its OAuth action with CLI instructions or a credential input.
Show sanitized connection and resource identifiers plus an actionable recovery step. Never accept or echo secret values in the browser. Provision or repair resources through reviewed ChangeRequests when required. A recovery step may ask the operator to initialize, retry, select a Space, or review one named CR; it must not delegate Node/Base construction or id wiring to them.
应用
references/setup-onboarding.md
规范。即使Busabase未就绪，应用也需支持启动明确的本地预览；托管的AirApp需显示一个配置/引导网关，而非静默切换到本地或Demo数据。区分运行时就绪与产品引导。
运行时就绪状态包括：
  • 缺失连接引导；
  • 未认证或Busabase不可达；
  • Space不明确或不可访问；
  • 缺失应用Folder/资源；
  • 需要schema迁移；
  • 缺失Vault引用；
  • 就绪。
产品引导单独涵盖工作流所需的持久运营上下文、策略、数据源、调度、阈值及审批规则。其字段及完成/版本状态需存储在Busabase中。产品先决条件未完成时，请勿启用外部读取或重大操作。
在产品覆盖层及机器可读蓝图中声明引导合约，包含正整数
version
、明确必填字段、其所属Base/Doc资源键、验证规则及每个字段解锁的操作。无引导要求的产品需声明明确的空合约及理由；省略不等于「无要求」。将
onboarding_version
、完成状态及实例化完成时间存储在声明的Busabase资源中。版本不匹配时进入
needs_review
或
migration_needed
状态，绝不能标记为
complete
。
对于缺失或过期的认证，应用上述连接UX合约；请勿将其OAuth操作替换为CLI指令或凭据输入。
显示已脱敏的连接及资源标识符，加上可执行的恢复步骤。请勿在浏览器中接受或回显密钥值。必要时通过已审核的变更请求预置或修复资源。恢复步骤可要求操作员初始化、重试、选择Space或审核指定变更请求；但不得将节点/Base构建或ID关联工作委托给操作员。

Completion Criteria

完成标准

Finish only when:
  • the skill contains a complete canonical app-root project and 
    pnpm --dir <app-root> dev
    remains supported, whether or not local preview was requested;
  • $busabase-app-creator
    runtime, SDK, security, validation, and deployment checks pass without a conflicting local runtime contract;
  • $kelly-app-skill-creator-tests
    required local and OSS suites pass, and its Cloud/AirApp suites pass when their declared environment is available; skipped external suites are reported explicitly;
  • the Busabase connection, target Space, app root, and resource map are explicit;
  • all persistent config, state, decisions, claims, and domain data use 
    busabase-sdk
    and appropriate Busabase nodes;
  • Vault values and API credentials never reach browser-visible surfaces;
  • local setup offers Cloud/custom URL OAuth plus an explicit Demo path, while deployed AirApp uses its ambient session;
  • local OAuth verifies accessible Spaces, auto-selects a single/open-source Space, requires an explicit selector choice for multiple Spaces, and performs no resource initialization before that choice;
  • the local Hono boundary consumes 
    busabase-sdk/airapp-node
    , ignores inbound Space headers, and branches on stable Space reasons;
  • Research, Plan, Action, and Retrospective are represented or intentionally omitted;
  • human attention, opt-out, review, and Agent claim rules are unambiguous;
  • runtime readiness, product onboarding, review verdicts, Agent revision, external execution, and recovery obey their selected reference contracts;
  • the blueprint declares onboarding version, required fields, Busabase storage, validation, and unlock rules, or an explicit empty contract with rationale;
  • local and AirApp runs use the same application source and resource contract;
  • the default delivery produced a merged, verified AirApp and a clickable target URL; a local URL is reported only for an explicitly requested local preview;
  • the Kelly desktop sidebar, attention, workflow navigation, list/detail, hash routing, and Help & Settings contract is implemented where applicable;
  • 1280px desktop, 390px phone, and 360px narrow-phone workflows pass visual, interaction, and horizontal-overflow checks;
  • validation, deployment, and real-data checks required by dependency skills pass, and were verified as described in "A Green Suite Is Not An Acceptance".
仅在满足以下所有条件时才算完成：
  • 技能包含完整的标准应用根目录项目，且无论是否请求本地预览，都支持
    pnpm --dir <app-root> dev
    ；
  • $busabase-app-creator
    的运行时、SDK、安全、验证及部署检查通过，无冲突的本地运行时合约；
  • $kelly-app-skill-creator-tests
    要求的本地及开源测试套件通过，且当声明的环境可用时，其云端/AirApp测试套件也通过；需明确报告跳过的外部测试套件；
  • Busabase连接、目标Space、应用根目录及资源映射表明确；
  • 所有持久化配置、状态、决策、声明及领域数据都使用
    busabase-sdk
    及相应Busabase节点；
  • Vault值及API凭据从未出现在浏览器可见界面；
  • 本地配置提供云端/自定义URL OAuth及明确的Demo路径，而部署的AirApp使用其会话环境；
  • 本地OAuth验证可访问的Space，自动选择单个/开源Space，多个Space时需明确选择，且在选择前不执行任何资源初始化；
  • 本地Hono边界使用
    busabase-sdk/airapp-node
    ，忽略传入的Space头，并根据稳定的Space原因分支处理；
  • 研究、规划、执行及回顾阶段已体现或明确省略；
  • 人工注意力、退出、审核及Agent申领规则明确无歧义；
  • 运行时就绪、产品引导、审核裁决、Agent修订、外部执行及恢复遵循选定的参考合约；
  • 蓝图声明了引导版本、必填字段、Busabase存储、验证及解锁规则，或明确的空合约及理由；
  • 本地与AirApp运行使用相同的应用源码及资源合约；
  • 默认交付生成了已合并、已验证的AirApp及可点击的目标URL；仅在明确请求本地预览时才报告本地URL；
  • Kelly桌面端侧边栏、注意力、工作流导航、列表/详情、哈希路由及帮助与设置合约已在适用处实现；
  • 1280px桌面端、390px移动端及360px窄屏移动端工作流通过视觉、交互及水平溢出检查；
  • 依赖技能要求的验证、部署及真实数据检查通过，并按照「测试通过不等于验收完成」部分所述进行验证。

A Green Suite Is Not An Acceptance

测试通过不等于验收完成

Passing tests say the cases you thought of hold. Before reporting a change as verified, exercise it the way a real caller will:
  • Run the actual command against a real instance, not only the unit cases. A pure-assertion check of an integration is a statement about your assumptions.
  • Confirm a new regression test fails without its fix. A test written after the diagnosis usually passes either way; one that cannot fail proves nothing. Revert the fix, watch it go red, restore it.
  • Ask which variant the existing test happened to take. A round-trip test that preserved server-owned ids stayed green through a bug that blanked every secret in the scope, because the failing path was the variant nobody wrote.
  • Suspect the environment before the diagnosis. A stale local database, an absent encryption key, or missing 
    node_modules
    produces failures that look exactly like a regression in the change under review. Establish which it is before concluding anything.
  • Re-check downstream assumptions after changing a shared surface. A fix that makes a previously-404 route work turns every client's untested error path into a live code path. Ship the client-side follow-up with it, not after a user finds it.
Report what was actually executed and what was skipped. "Tests pass" without saying which environment they ran in is not a result.
测试通过仅说明你考虑到的场景正常。在报告变更已验证前，需以真实调用者的方式测试：
  • 针对真实实例运行实际命令，而非仅运行单元测试。纯断言的集成检查只是对你假设的验证。
  • 确认新的回归测试在无修复时会失败。诊断后编写的测试通常无论是否修复都会通过；无法失败的测试毫无意义。先撤销修复，观察测试失败，再恢复修复。
  • 询问现有测试采用了哪种变体。保留服务端自有ID的往返测试在一个清空范围内所有密钥的bug中仍显示绿色，因为失败路径是无人编写的变体。
  • 在诊断前怀疑环境问题。过时的本地数据库、缺失的加密密钥或缺失的
    node_modules
    会产生与变更回归完全相同的失败。在得出结论前需确定原因。
  • 修改共享接口后重新检查下游假设。修复某个之前返回404的路由会将每个客户端未测试的错误路径变为活跃代码路径。需同时发布客户端后续修复，而非等用户发现后再处理。
报告实际执行的内容及跳过的内容。仅说「测试通过」而不说明运行环境不是有效结果。

Stop Conditions

停止条件

Stop when a dependency is unavailable for the next required operation, the target Space or app root is ambiguous, node capabilities cannot support the intended model, a secret would cross into the browser, a side effect lacks a reviewed trusted-execution path, or local and AirApp implementations would require separate business logic.
当以下情况发生时停止：下一个必需操作的依赖不可用、目标Space或应用根目录不明确、节点能力无法支持预期模型、密钥将进入浏览器、副作用无已审核的可信执行路径，或本地与AirApp实现需要分离的业务逻辑。",