Web Device compatibility has more than one moving part: the installed ARC CLI/runtime, the source checkout that may be ahead of it, a site’s source conventions, and generated compatibility material. Similar version names do not make those things interchangeable.
Evidence used by this first board
| Claim type | Current evidence boundary |
|---|---|
Serve-time content access gate, first-screen teaser, access-gate | arc 2.0.0-beta.35 after arc#4065; local capture on http://arcblock.localhost:4922/ 2026-08-15 |
| Local command paths and minimal-site acceptance | arc 2.0.0-beta.25 in an isolated local environment |
| Markdown Slides | A local ARC source build that contains the Web Device slides widget; no released version boundary is recorded on this board yet |
| Runtime implementation semantics | Current ARC source inspected while writing this board |
| Historical Cookbook/articles/issues | Context and design history only; not the default current contract |
When this page says a command was “run,” it means that command was exercised on beta.25 unless the page records another target. Markdown Slides is a newer source-level contract: verify that the target build contains the slides widget before relying on it. When this page says the runtime “currently reads” a directory or chooses a layout, it is sourced from the inspected implementation and should be rechecked if the installed version differs.
Check before copying a pattern
arc --version
arc dsl validate .
arc blocklet check .
arc blocklet build .
arc blocklet run .Use the installed version and the actual local output as the compatibility decision. If a historical site or article uses a different pattern, preserve it until the target version has been run; do not bulk-convert it just because a newer documentation page uses a newer source-first form.
Keep compatibility artifacts in their own lane
JSON layouts/configuration and split .web files can remain supported compatibility forms. A new site should prefer the current documented AUP and site.yaml forms, but generated or historical files must only be removed after the concrete consumer has passed. A build that succeeds on one runtime does not prove an older deployment/runtime accepts the same source.
Record the CLI/runtime version, route, locale, browser/device target, and observed result with any UI acceptance evidence. That is more useful than claiming unqualified “latest” support.