Two workspace profiles, one URL contract
External
A real app repository pins arcane-os in npm and maps the synchronized SDK runtime into packaged /arcane URLs.
Integrated
An Arcane OS checkout uses its live arcane/ runtime without adding an SDK self-dependency. Initialization creates only app-owned files.
Responsibility follows ownership
| Owner | Owns | Does not own |
|---|---|---|
| Application | Source, descriptor, tests, policy, adapter, release | Shared Arcane runtime or native provider |
| SDK | CLI, schemas, runtime mapping, packaging, receipts, orchestration | Application business logic or platform toolchain discovery |
| Arcane OS | Core, native hosts, explicit target providers, admission | External app source or app-owned test execution |
The descriptor and release are different artifacts
apps/<id>/arcane-app.json is the authored schema-2 identity and policy. It projects the current schema-1 package contract. Packaging produces dist/<id>/ARCANE_APP_RELEASE.json with the positive inventory; a release bundle adds the canonical descriptor and exact payload without repository-only source.
Native providers are explicit pairings
The SDK never searches for a mutable global toolchain. A native command names one target and one --arcane-root; the selected Arcane checkout supplies the fixed provider module for that process generation.
doctor → prepare → plan → build → verify receipt → run receiptPortable intentionally stops before run. Other current development providers launch only on their compatible host or device.
Verify once for one exact state
A receipt binds canonical location, filesystem identity, app policy, inventory, hashes, toolchain, target, and one operation generation. Same-process consumers reuse it while those facts remain unchanged. A pathname, timestamp, environment variable, or JSON file alone is not authority.