Independent repository

Own the app. Pin the Arcane contract.

An external repository owns its source, tests, adapters, license, and publication. The SDK supplies the checked runtime, CLI, schemas, and deterministic bundle boundary.

Profile: externalDefault unit: one appSource stays independent

Authority and result

The external repository may use private or proprietary source, but it cannot borrow authority from the Arcane checkout. Its lockfile pins the SDK; its descriptor declares permissions, security, Core requirements, and target intent; and its application release owns the complete packaged content.

App repository ownsSource, behavior tests, adapters, licensing, version, and publication.
SDK ownsCLI contracts, schemas, synchronized runtime, packaging mechanics, and bundle verification.
Arcane OS ownsAdmission policy and installation of an independently authorized release.

1. Create or enroll the repository

Use new for a repository-shaped browser scaffold. Use init when source already exists and only the missing Arcane files should be added. Native targets use the separate provider-paired guide.

Published arcane-os 0.5.18 · new browser repository
npx arcane-os@0.5.18 new my-app --path ./my-app --target browser --git
cd my-app
npm install
Enroll an existing browser repository
npm install --save-dev --save-exact arcane-os@0.5.18
npm exec -- arcane init my-app --target browser

2. Use the focused app loop

The generated scripts select one app and acknowledge before blocking work. Start the source server and refresh after saving. Tests and checks are separate explicit operations.

Application repository
npm exec -- arcane dev

Expected: the development server prints its selected application URL and keeps serving saved source until cancelled.

3. Package the selected browser output

package creates the selected browser release and verify checks the published inventory. Use --dry-run to inspect the planned source set without creating output.

Package boundary
npm exec -- arcane package --dry-run
npm exec -- arcane package
npm exec -- arcane verify
Do not hand-edit generated release records.

Change the canonical descriptor or package inputs and package again. A stale or edited ARCANE_APP_RELEASE.json must fail verification.

4. Create the deterministic exchange bundle

The bundle contains the schema-2 descriptor and one already packaged release, including its packaged HTML, CSS, and JavaScript. It omits repository-only source, tests, and development files, and it does not execute an adapter while Arcane admits it.

Release bundle
npm exec -- arcane package --app my-app
npm exec -- arcane bundle --app my-app
npm exec -- arcane verify-bundle dist/my-app-0.1.0.arcane-app.tar.gz

Expected: one deterministic .arcane-app.tar.gz containing the descriptor, release manifest, and complete ordered inventory.

5. Keep CI exact and narrow

Dependency installation uses the application’s committed lock. Run tests or checks only when explicitly selected. The reusable application release workflow is not a supported path until its implementation matches the current publishing contract; see the maintained publishing guide.

Evidence is not authority by itself.

An uploaded bundle is the selected application output. Native installation and host capabilities remain the receiving application or host owner’s responsibility; ordinary packaging creates no provenance or verification receipt.

Licensing boundary

The synchronized Arcane runtime and packager are currently AGPL-3.0-only. The existing commercial notice is not, by itself, permission to distribute a closed-source application that bundles that runtime; obtain the separate agreement required for that use.

Read the repository licensing notes