ARC supports both readable DSL source and JSON source for the same AUP model. The important distinction is not “new versus old”; it is which file is the current source for a particular app and which file is merely a compatibility artifact.
App-configuration loading order
For the app configuration boundary in ARC 2.0.0-beta.25:
- If
.aup/app.aupexists, ARC uses it as source. - If it does not exist, ARC can read
.aup/app.jsonas JSON source. - If the DSL file exists but cannot be compiled, the load fails. ARC does not silently substitute an old JSON file.
That third rule is deliberate: a stale artifact must not make a broken source appear healthy.
Three legitimate project shapes
| Shape | Source of truth | When JSON exists |
|---|---|---|
| JSON-first | The authored JSON files | They are the source, not a compatibility residue |
| DSL-first, virtual artifacts | .aup files | ARC can expose compatible JSON without putting each artifact on disk |
| DSL-first, materialized artifacts | .aup files | A named compatibility consumer requires physical JSON files |
The regular AUP Showcase is a useful reminder that JSON-first remains supported. Conversely, the existence of generated JSON beside a DSL source does not make JSON the authoring authority.
Do not infer a release contract from a file list
Generated app, page, or wrapper JSON can vary by source and consumer. A file being present in one recipe or Showcase tree is not proof that every AUP app must commit it. When a consumer needs materialized output, use arc dsl generate --check first, then --write, and record that consumer in the project’s own delivery contract.
The compatibility boundary is intentionally narrow: it does not promise that every historical JSON layout, every physical Showcase page, or every generated artifact is a current deployed surface. Verify the current source, registered configuration, and target runtime separately.
See Generate, lint, and migrate for the workflow and Release compatibility for version boundaries.