Current source example; read scope not universally accepted

Example: AFS data binding

Use the DSL Showcase list-template source to distinguish a runtime AFS list from a compile-time loop, then verify scope on the actual target.

The current DSL Showcase contains a list-template source example built around afs-list. It is useful because it shows the opposite of a compile-time for: the item template is rendered from a runtime data list rather than expanded from a literal array.

Read the example at the correct layer

afs-list expresses a runtime list/template intent.
The data path is resolved through the runtime/AFS path boundary.
A renderer and session still determine whether the result can be presented.
Readability of a path does not imply write permission, exec permission, or a portable renderer experience.

Do not convert the sample into a generic promise that a particular legacy alias or sample path exists in every blocklet. Use the current product’s declared path and a real caller/session when testing.

Acceptance sequence

Declare the smallest read-only source path for the app under test.
Run source validation and the relevant blocklet checks.
Start the registered app locally with a caller/session that is entitled to the path.
Observe the item template, an empty result, and a denied/unavailable result distinctly.
Only add bindings or actions after the read boundary is understood.

This page deliberately does not turn a Showcase source file into a public data endpoint. For source syntax, see Nodes, values, and sugar; for authorization, see Caller identity and safety.