メインコンテンツへスキップ

ARC 2.0.0-beta.28

Lifecycle

Separate local observation, package checks, build artifacts, and remote publish/deploy as distinct lifecycle stages.

Lifecycle documentation is useful only when state boundaries stay visible. Collapsing "it builds" into "it is deployed" is a common failure mode.

Stages

StageWhat changesTypical commandsEvidence
AuthorPackage sourceeditor, createDiff in VCS
ValidateNothing durabledsl validate, blocklet check, dsl lintPass/fail + issue list
Local instanceDaemon registration / serveblocklet run, service start --blockletPrinted URLs + browser
Builddist/ artifactblocklet buildFile count, manifests, instance: line
Local daemon registerExtra blocklet dirs on a running daemondeploy <path> (no flags), service start --blockletdeploy list
Local DID Space publishDeveloper space tree under /blocklets/<id>/deploy <path> --publishdeploy show / list --published
Remote DID Space publishRemote server writedeploy <path> --server <url>Auth + remote inspection — often unverified here
Pages / fleet deployCDN/Pages projectblocklet deploy, blocklet fleet, blocklet instancePlatform-specific verify

Default path for developers

text
create → validate → local run → browser accept
                 ↘ build (when you need an artifact)

Only after local acceptance, choose a publish path that matches the release goal. Details and honesty markers: Publish and deploy.

Child pages

PageFocus
Test and diagnoseFailure modes, what each check means
Publish and deployLocal publish vs remote; experimental labels

Stateful features

If arc blocklet build reports instance: requires /instance DID Space, the package has instance-axis dependencies. Lifecycle for those features includes:

  1. Package validation (always)
  2. Local shell/page serve (may succeed without full instance data)
  3. Bound instance DID Space for real writes (separate proof)

Do not mark stage 3 complete because stage 2 returned HTTP 200.

Stop cleanly

For temporary acceptance:

bash
arc service stop

Only stop the isolated service you started. Persistent developer daemons are an environment choice, not a documentation requirement.