ARC has several developer surfaces. They are related, but they do not share one undifferentiated contract. Use this board to choose the right layer before following a task-specific guide.
| If you need to understand | Read next | Do not infer |
|---|---|---|
| Path-based resources and provider behaviour | AFS | A global search, storage, or provider capability that has not been documented for the target runtime |
| A declarative interface tree, state, or renderer boundary | AUP | That every AUP node has the same support on every target |
| A static site backed by AFS paths | Web Device | That a site layout is an interactive AUP session |
| A package and instance lifecycle | Blocklets | That every older Blocklet Server behaviour remains part of ARC |
| Identity, a DID Space, or a data-space term | Identity & Data Spaces | A complete remote lifecycle or trust model that has not been verified end to end |
| How CLI commands map to these layers | ARC CLI | That every CLI group is a separate product with its own public API |
System map
Read the stack from the bottom up when you need a resource, and from the outside in when you need a product boundary:
| Layer | What it answers | Primary developer surface |
|---|---|---|
| AFS | How do I address data and capabilities by path? | Operations, mounts, providers |
| AFS UI | How do UI concerns relate to AFS resources? | Architecture lens only (this board) |
| AUP | How do I describe an interactive interface tree? | Declarative UI contract and DSL |
| Web Device | How do I build and render a static site? | Site directories, content, components |
| Blocklet | How do I package and run an application? | Package, instance, local run, publish boundary |
| Identity / data spaces | Who is calling, and which data view do they get? | Caller context, DID Space, session views |
| ARC + CLI | How do I start, inspect, and operate the runtime? | arc commands and the host process |
AFS is the resource and capability layer. ARC is the runtime and product shell that mounts providers, runs Blocklets, and exposes CLI and service entry points. AFS UI is not a third large authoring board equal to AUP or Web Device; it explains how those targets relate back to AFS.
For ownership and the layer diagram, see Product layers. For how ARC and AFS are named separately, see ARC and AFS.
A map, not a substitute for a contract
The architecture map may explain why two parts belong together. It does not turn an internal plan, an old product page, or a source directory into a public API. Treat current source, target-version tests, and a local run as the evidence for a present-tense claim. Classification rules live on Contracts and evidence.
The phrase AFS UI appears in ARC architecture material as a way to relate UI concerns to AFS-oriented resources. In this board it is an architectural lens, not an independent public extension API. AUP and Web Device remain separate, target-specific documentation surfaces.
Read by task
| Goal | Start here |
|---|---|
| Learn the vocabulary and reading order | Mental model |
| Separate ARC (runtime) from AFS (filesystem) | ARC and AFS |
| Choose which board owns a task | Product layers |
| Place interactive UI vs static sites on AFS | AFS UI |
| Decide whether a claim is current contract or lineage | Contracts and evidence |
| Resolve an older ArcBlock product name | Product lineage and boundaries |
| Collect public board links and terms | Reference |
Version boundary
Facts on this board were checked against:
- Installed CLI:
arc2.0.0-beta.28(arc --version) - ARC source snapshot:
44fbd616f(packages/core,packages/aup,providers/runtime/ui,providers/runtime/web-device,providers/basic/did-space,providers/basic/members) - Package names observed in that tree:
@aigne/afs,@aigne/afs-aup,@aigne/afs-ui,@aigne/afs-web-device,@aigne/afs-did-space(each2.0.0-beta.31in source)
Task-specific commands, fields, and renderer support belong on the sibling boards. Re-check those boards when your installed arc version differs.