Example: minimal app

minimal-app is the smallest currently documented complete ARC app recipe. It is deliberately more than a single AUP file: the recipe provides one Web page, one AUP app, one agent, and a settings-shell source/defaults. Its profile checks declared pages/capabilities and structural limits; it does not by itself prove that every capability has a live end-to-end instance configuration.

Reproduce the example

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

On ARC 2.0.0-beta.25, creation reports 18 files and prints an absolute path for the next validation step. The local run prints both a <name>.localhost URL and a universal query URL; use the first in Chrome/Firefox and the query URL where the subdomain form is not available.

What was actually accepted

The recipe was created in an isolated local directory, then formatted, linted, validated, and checked against minimal-app. In a direct local run, the root screen showed the app name, App, Agent, and Settings, plus the recipe’s “A tiny complete app.” description. That confirms the bounded local route, not an external deployment or every possible renderer/device interaction.

The settings defaults are seeded into /instance at activation time. A new scaffold and a passing profile should therefore not be described as already carrying a live user-instance setting before that activation boundary exists.

Extend it without losing the evidence

For the source/artifact distinction, read Sources, artifacts, and JSON compatibility. A minimal static content site is a separate target-specific Web Device path, not a variant of this complete-app recipe.