minimal-app 是当前文档化的最小完整 ARC app recipe。它有意不只是一份 AUP 文件：recipe 提供一个 Web page、一个 AUP app、一个 agent，以及 settings-shell source/defaults。它的 profile 检查声明的 page/capability 与结构限制；这本身不证明每种 capability 都有 live 的端到端 instance 配置。
复跑此例子
arc blocklet recipe explain minimal-app
arc blocklet create ./hello-aup --recipe minimal-app --name hello-aup
arc dsl format ./hello-aup --write
arc dsl lint ./hello-aup
arc dsl validate ./hello-aup
arc blocklet check ./hello-aup --profile minimal-app
arc blocklet run ./hello-aup在 ARC 2.0.0-beta.25 中，创建会报告 18 个文件，并把下一步 validation 写成绝对路径。local run 会打印一个 <name>.localhost URL 和一个通用 query URL；Chrome/Firefox 用前者，不能使用子域名形式时用 query URL。
实际验收了什么
recipe 在隔离本地目录创建，随后经过 format、lint、validate 和 minimal-app profile check。直接本地运行时，根页面显示 app name、App、Agent、Settings 以及 recipe 的 “A tiny complete app.” 描述。它证明的是有边界的本地 route，不是外部部署，也不是所有 renderer/device interaction。
settings defaults 在 activation 时才 seed 到 /instance。因此新的 scaffold 和通过的 profile 不应被写成在 activation 边界之前已经带有 live user-instance setting。
在不丢失证据的情况下扩展
- 保留第一次原样运行，并记录浏览器结果。
- 每次只改一类 source：一个 page、一个 interaction 或一条已声明 data path。
- 重跑命令链，并检查拥有该声明的 target。
- 只有核对 compatibility artifact 时使用
generate --check；source-first local app 不依赖它才能运行。
source/artifact 区分见来源、artifact 与 JSON 兼容性；最小静态内容站点是另一条 target-specific 的 Web Device path，不是这个完整 app recipe 的变体。