ARC 对同一个 AUP 模型同时支持可读的 DSL source 和 JSON source。关键区别不在“新”或“旧”，而在于某个 app 当前哪份文件是 source、哪份只是兼容产物。
app 配置的读取顺序
在 ARC 2.0.0-beta.25 的 app 配置边界内：
.aup/app.aup存在时，ARC 将它作为 source。- 它不存在时，ARC 可以把
.aup/app.json作为 JSON source 读取。 - DSL 文件存在但无法编译时，读取会失败；ARC 不会悄悄改用旧 JSON。
第三条是有意的：陈旧产物不应让一个已经损坏的 source 看起来正常。
三种都合理的项目形态
| 形态 | 权威 source | JSON 何时存在 |
|---|---|---|
| JSON-first | 人直接维护的 JSON 文件 | 它们是 source，不是兼容残留 |
| DSL-first、虚拟产物 | .aup 文件 | ARC 可以暴露兼容 JSON，但不必逐个写到磁盘 |
| DSL-first、物化产物 | .aup 文件 | 某个明确的兼容消费者要求实体 JSON 文件 |
普通 AUP Showcase 提醒我们 JSON-first 仍受支持。反过来，DSL source 旁边出现生成的 JSON，也不代表 JSON 成为编写时的权威。
不要从文件清单推断发布合同
生成的 app、page 或 wrapper JSON 会随 source 和消费者而变。某个 recipe 或 Showcase 树中出现一份文件，并不证明每个 AUP app 都必须提交它。消费者需要实体输出时，先运行 arc dsl generate --check，再用 --write，并在项目自身的交付合同中记下这个消费者。
兼容边界刻意保持很窄：它不承诺每一种历史 JSON layout、每个 Showcase 的实体页面或每份生成产物都是当前已部署界面。应分别核验当前 source、已注册配置和目标运行时。
工作流见 生成、lint 与迁移；版本边界见 发布兼容性。