arcane-os 0.1.0-dev.5

package/bin/arcane.mjs

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+
+import {runCli} from '../src/cli/main.mjs';
+
+process.exitCode=await runCli();

package/docs/architecture.md

@@ -0,0 +1,234 @@
+# Architecture
+
+The CLI, future Arcane Developer graphical control panel, CI, and Codex all use
+one headless operation API. A client selects a named operation and consumes the
+same structured event stream; the GUI is not a second build system.
+
+```text
+external app repository -----+
+                              |
+integrated Arcane checkout ---+-- CLI / future GUI / Codex / CI
+                                      |
+                               shared toolchain API
+                                      |
+                       browser package or explicit target adapter
+```
+
+## Workspace profiles
+
+An external workspace maps the exact runtime shipped by its locked `arcane-os`
+dependency. An integrated workspace maps the live `arcane/` and
+`node_modules/strong-type` directories already owned by the Arcane checkout.
+The development server and packager consume the same route destinations in
+both cases, so app imports do not change. Integrated initialization creates
+only app-owned files and never rewrites Arcane root configuration.
+
+The shared/Core development profile is a separate integrated-only scope selected
+with `--scope shared`. The SDK loads exactly
+`tools/integrated-development-provider.mjs` from the selected Arcane checkout as
+one process generation. That provider admits only one exact repository-relative
+focused `.test.mjs` through Arcane's canonical focused runner or Arcane's
+canonical development check. External workspaces cannot use the scope, and
+shared operations never enter app discovery, packaging, target planning, build,
+verification, or run paths. Provider bytes and filesystem identity are
+authenticated before and after the owned child operation; a generation change
+poisons that pairing and requires a new CLI process.
+Integrated app testing remains isolated to the selected `apps/<id>/test/`
+tree; it cannot recursively select Arcane root tests or another app's tests.
+External repositories retain their existing workspace-root plus selected-app
+test layout.
+
+## App and release contract
+
+The first SDK version deliberately preserves Arcane's current repository-shaped
+URLs and release schema:
+
+```text
+apps/<id>/arcane-app.json
+apps/<id>/arcane-package.json
+apps/<id>/index.html
+dist/<id>/ARCANE_APP_RELEASE.json
+```
+
+The authored schema-2 descriptor is canonical for new apps and projects an
+exact schema-1 `arcane-package.json` for current consumers. Existing Arcane
+apps synthesize that descriptor from their schema-1 package plus the current
+native registry during migration.
+
+An external app's `arcane-packager.json` has three exact shared routes. They map the
+installed SDK runtime to `/arcane`, its vendored strong-type dependency to
+`/node_modules/strong-type`, and the SDK's `LICENSE`,
+`COMMERCIAL-LICENSE.md`, and `NOTICE` to `/licenses/arcane-os`. The app does not
+copy Arcane runtime source into its repository.
+
+Release schema 1 and builder identity `arcane-app-packager-v1` remain unchanged
+because current Arcane native admission treats them as exact contracts. Native
+builders authenticate the schema-2 descriptor digest as a
+separate build input while exact v1 host artifacts remain unchanged.
+
+External repository delivery adds a distinct schema-1
+`arcane-app-release-bundle` envelope. Bundle creation accepts only a
+process-authenticated release receipt whose descriptor authority was an authored
+schema-2 `arcane-app.json`; a synthesized legacy descriptor remains valid for
+integrated packaging but cannot cross the external admission boundary. The
+archive contains exactly `ARCANE_APP_BUNDLE.json`, canonical `arcane-app.json`,
+`payload/ARCANE_APP_RELEASE.json`, and the release inventory beneath `payload/`
+in that order. The envelope adds no repository-only source or build tooling
+beyond that authenticated release inventory. Individual apps remain responsible
+for leak/source policy, and Arcane's source-free runtime gates remain separate.
+
+The byte contract is deterministic USTAR with regular 0644 files, zero owner
+ids and modification times, canonical UTF-8 paths and headers, exact zero
+padding, and exactly two terminal blocks, wrapped in one deterministic gzip
+member. NFC inventory paths use raw UTF-8 byte order, not host locale collation;
+the packager, bundle verifier, and Arcane importer share that ordering, while a
+pinned golden bundle digest runs across the supported Node and runner matrix.
+
+Verification parses the expanded stream without extraction, applies absolute
+size/cardinality and expansion-ratio ceilings, recompresses the stream to
+require the exact gzip encoding, and rejects appended bytes or concatenated
+members. Every source control, payload, staged archive, and verification input
+is opened no-follow as a single-link regular file, consumed at its recorded
+length with an EOF growth probe, and rechecked by handle and pathname identity.
+Every cumulative path prefix has one case-folded spelling and one file/directory
+kind; prefix topology conflicts and the complete portable Windows device-name
+set fail before creation or admission.
+The current SDK admits only the explicitly compatible `0.1.0-dev.5` bundle
+generation and rejects zero-byte payload releases.
+
+Promotion retains any prior output as an identity-bound backup until the new
+pathname has passed a second exact-length digest and single-link identity check
+and its immutable receipt is bound. Pre-commit failure restores that backup
+only when both the promoted pathname and prior backup retain their respective
+full recorded identity tuples, pinned by their open handles. A replaced or
+in-place-changed output is never removed during rollback; it and the prior
+backup remain available for inspection. A missing or changed backup likewise
+causes rollback to preserve the valid promoted output rather than delete it.
+Post-commit backup or
+nonce-bound lock cleanup failure is surfaced as degraded cleanup and preserves
+the uncertain path for inspection. The receipt exposes
+artifact digest/bytes, descriptor canonical/file/package digests and bytes, and
+release manifest/policy/content digests, file count, and total payload bytes.
+These hashes prove internal consistency. Repository provenance or an
+independent signature plus an Arcane-owned authorization lock remains the
+separate installation authority.
+
+The reusable app-release workflow keeps caller checks and adapters in a
+`contents: read` build job. A fresh unprivileged job downloads the immutable
+upload by artifact id, checks the requested app id and complete identity with the
+exact called-workflow SDK, and alone supplies reusable outputs. Its conditional
+attestation job redownloads the same artifact id, repeats those checks against
+the post-upload outputs, and directly imports the dependency-free verifier from
+the trusted source checkout under supported Node 24 via the pinned
+`actions/setup-node` revision. No package-manager install, dependency
+resolution, caller checkout, or caller code runs while OIDC and
+attestation-write authority is present.
+
+## Operation ownership
+
+An invocation defaults to one workspace, one app, one command, one target, one
+architecture, one format, and one signing profile. It acknowledges before long
+work, uses one `AbortController`, supervises child processes, and routes progress
+through one serialized owned event queue. Process streams apply pause/resume
+backpressure and heartbeats coalesce. Callback failure cancels owned work, drains
+the queue, and reaches the caller or CLI exit status. Packaging preserves prior
+output until verified replacement.
+
+Each normalized queue event is also mirrored exactly once through the shared
+`arcaneEvents` `EventManager`. That synchronous `event-pubsub` route is the
+canonical cross-cutting instrumentation surface, but it does not replace the
+owned asynchronous callback path or its backpressure. Time-travel history and
+DOM observation remain explicitly disabled unless a bounded diagnostic session
+enables them. See [event-manager.md](event-manager.md) for the record, redaction,
+DOM coverage, and effect-isolated playback boundaries.
+
+For `--scope shared`, the cardinality changes to one integrated workspace, one
+named operation, and either one exact test file or one development check. The
+same owned event queue and process supervisor provide acknowledgement, bounded
+stream delivery, heartbeat, cancellation, process-tree cleanup, and nonzero
+failure propagation. No app or target loop exists in that scope.
+
+## Verification receipts
+
+Runtime verification binds the exact SDK version, upstream Arcane commit,
+runtime inventory, byte counts, and SHA-256 hashes. Packaging writes the full
+schema-1 release inventory to `ARCANE_APP_RELEASE.json`; its operation result
+returns a deeply immutable, process-authenticated receipt that binds the
+canonical location, app policy, complete inventory, content digest, and verified
+filesystem identities. The browser run path authenticates that receipt before
+serving it, and every native provider consumes release bytes through SDK-bound
+verified readers before verifying its app-scoped artifact. Windows and Linux
+retain artifact authority for same-process verification and launch. Persistent
+cross-process reuse still requires an authenticated Arcane broker; a path,
+timestamp, environment variable, or receipt file alone is not authority.
+
+The loopback server treats the mutable filesystem as an input, not as an
+immutable receipt. Before sending headers it reads each requested source,
+runtime, or packaged file into a bounded buffer, verifies the expected hash for
+receipt-bound files, and repeats the handle/path identity check. A response is
+therefore an exact verified byte snapshot even if another process writes during
+the request. Development serving is limited to 64 MiB per file and four active
+file responses, with a bounded wait queue.
+
+## Native provider boundary
+
+The SDK implements protocol `arcane-native-build-plan/1` and the injected
+provider contract `arcane-native-builder/1`. Pairing is process-local; it never
+registers a mutable global provider or searches for a toolchain. For each
+supported native target, the CLI loads one fixed provider module from the
+explicit `--arcane-root` Arcane OS checkout. Provider code is bound to one
+process generation; if a pull changes any loaded provider module, the SDK fails
+closed and requires a fresh worker rather than combining new hashes with Node's
+cached old modules. One paired toolchain can perform this lifecycle:
+
+```text
+doctor -> prepare -> plan -> build -> verify receipt -> run receipt
+```
+
+The portable provider implements the lifecycle through verification and fails
+honestly on run because its result is a directory. Windows x64, Linux x64,
+Linux ARM64, and Android ARM64 implement same-process launch and owned
+cancellation when their compatible host/device requirements are present.
+Windows uses a retained per-build broker and authenticated host readiness. The
+Linux provider produces a verified amd64 or ARM64 DEB and runs a retained
+user-owned extraction without install or elevation. Portable, Windows, and
+Linux use the `unsigned-local-test` signing profile.
+
+The Android provider produces one development-signed APK. It contains no native
+library or ABI-specific payload, so the artifact is architecture-neutral; the
+`android-arm64` target instead binds the supported run path to one physical
+device with native ARM64 support. APK is the only Android format in this
+development provider. AAB, release signing, publishing, and update continuity
+remain outside it.
+
+The plan binds one explicit `toolchainRoot` and authenticated receipt, one app
+release root and receipt, its approved schema-2 descriptor digest, only its
+declared dependency releases, one non-overlapping output root, and one target,
+platform, architecture, format, and signing request. App source and workspace
+paths are withheld from the native provider. The provider copies release bytes
+through SDK-bound verified readers rather than accepting a mutable source path
+as authority. Build completion requires provider verification, and later
+verify/run calls receive the exact artifact receipt.
+
+The SDK `0.1.0-dev.5` runtime requires Arcane `0.8.12` or newer. Compatibility
+is contractual rather than exact-version pinning: the prepared Core must meet
+the highest minimum declared by the runtime, selected app, and bundled app
+dependencies; keep each app's Arcane protocol generation; and provide every
+declared feature, capability, and method. Missing requirements stop before
+provider build; a newer compatible Core is accepted. Exact hashes
+remain integrity identities, not compatibility rules. The provider paths have
+been validated from independent workspaces. They do not copy proprietary source
+into the Arcane checkout.
+
+See [compatibility.md](compatibility.md) for the complete app and bundled-app
+admission rule and the required handling of breaking contract changes.
+
+Linux ARM64 shares the implemented Linux provider, focused tests, and a
+target-scoped remote evidence workflow. At Arcane revision
+`4382043c09285ea203aa6daba1732660966ac409`, that workflow proved native AArch64
+toolchain, DEB, host/Core/bridge, retained verification, sandboxed WebKit
+readiness, and owned process-group cancellation. The hardened Android path has
+exact-SHA physical ARM64/API 37 build, process/generation/nonce readiness,
+cancellation, uninstall, and absence evidence. Neither record establishes
+production signing, installation, publishing, update continuity, release
+acceptance, or production readiness.

package/docs/compatibility.md

@@ -0,0 +1,36 @@
+# Arcane application compatibility
+
+Arcane application compatibility is a capability contract, not an exact
+runtime-version pin. An app may run on a newer Arcane Core when the host meets
+all of the app's declared requirements.
+
+For the selected app and every declared bundled app, admission requires:
+
+- the requested target is declared by that app;
+- the host Core version is greater than or equal to
+  `requirements.minimumCoreVersion`;
+- `requirements.arcaneProtocol` matches the host protocol generation;
+- every declared `requirements.features` entry is advertised by the host;
+- every declared `permissions.capabilities` entry is available; and
+- every declared `permissions.methods` entry is available.
+
+The effective Core floor for a build is the highest minimum declared by the
+SDK runtime, the selected app, and its complete bundled-app closure. The native
+build plan authenticates the host toolchain receipt and checks every member of
+that closure before a provider may read release bytes or mutate output.
+
+This permits normal non-breaking Arcane upgrades. For example, an app requiring
+Core `0.8.12` can run on `0.8.13` or `0.9.0` when the required protocol,
+features, capabilities, and methods are still present. A higher version does
+not override a missing contract.
+
+Breaking changes must be visible at the contract boundary. A host must not
+continue advertising an old protocol, feature, capability, or method when its
+meaning or guarantees are no longer compatible. It must instead change the
+protocol generation or contract identifier so admission fails closed before
+launch.
+
+Hashes and lock-file identities serve a different purpose. They establish
+which SDK runtime, release, toolchain, and artifact bytes were verified for one
+build state; they do not require the installed Arcane version to equal the
+app's minimum version forever.

package/docs/event-manager.md

@@ -0,0 +1,166 @@
+# Central event instrumentation and time-travel review
+
+`EventManager` is the preferred event instrumentation surface for new Arcane
+SDK code. It composes `event-pubsub` for synchronous delivery and adds Arcane's
+optional diagnostic record around that bus. Existing SDK operation queues mirror
+their normalized events through the shared `arcaneEvents` manager exactly once
+without replacing their awaited callback, backpressure, cancellation, or failure
+semantics.
+
+Import the dedicated host-neutral entry point:
+
+```javascript
+import {
+    arcaneEvents,
+    createEventManager,
+    PLAYBACK_RECORD_EVENT
+} from 'arcane-os/event-manager';
+```
+
+Prefer one manager for an application or process boundary. Publish semantic
+events through `instrument()` when source and correlation metadata are known:
+
+```javascript
+arcaneEvents.on('document.save.completed',event=>{
+    console.info('Saved',event.documentId);
+});
+
+arcaneEvents.instrument(
+    'document.save.completed',
+    {documentId:'example'},
+    {
+        source:'app:example',
+        category:'operation',
+        correlationId:'save-42'
+    }
+);
+```
+
+`on`, `once`, `off`, `emit`, `reset`, and `list` retain the synchronous
+`event-pubsub` contract. Synchronous subscriber exceptions propagate to the
+publisher. Subscriber promises are not awaited, so use the SDK's owned event
+queues for work whose completion, failure, or cancellation depends on an
+asynchronous callback.
+
+## Enable a bounded, complete event stack
+
+Time-travel recording is disabled by default. With the flag off, the manager is
+only a pub/sub bus: it captures no history, source stack, or DOM activity.
+
+```javascript
+const events=createEventManager({
+    timeTravel:true,
+    maxEvents:10_000,
+    dom:{
+        root:document,
+        captureInputValues:false
+    }
+});
+```
+
+It can also be enabled around a diagnostic session:
+
+```javascript
+arcaneEvents.enableTimeTravel({
+    dom:{root:document,captureInputValues:false}
+});
+
+// Exercise the scenario.
+
+arcaneEvents.disableTimeTravel();
+const serialized=arcaneEvents.exportStack();
+```
+
+While enabled, every manager event receives an immutable
+`arcane-event-stack/1` record containing the session and event ids, sequence,
+UTC and monotonic timestamps, source/category, correlation and causation ids,
+nested dispatch depth, a bounded payload snapshot, completion or failure
+outcome, and dispatch duration. Source stacks are `null` by default; explicitly
+set `captureStacks: true` only for a controlled local session. Stored strings,
+collections, object entries, nesting, source stacks, and error stacks remain
+bounded. The durable JSON shape is published as
+`arcane-os/schemas/event-stack.json`.
+
+The default event limit is 10,000 records. Recording retains the complete
+session until that limit. On the next attempted record, it appends exactly one
+`arcane.time-travel.overflow` marker, stops DOM observation, and disables
+recording. It never silently evicts a prefix or presents a partial tail as a
+complete session. Call `clearHistory()` before re-enabling recording. Tune
+`maxEvents`, `maxSnapshotDepth`, `maxSnapshotEntries`, and
+`maxSnapshotStringLength` for the diagnostic environment. The string limit has
+a minimum of 64 characters so generated structural markers remain importable.
+High-frequency
+pointer, touch, drag, scroll, and wheel events can reach the limit quickly.
+Arcane does not upload or persist a stack automatically.
+
+## DOM observation
+
+When a DOM root is attached while time travel is enabled, capture-phase
+listeners record the standard keyboard, pointer, mouse, touch, form, focus,
+clipboard, drag, selection, and scroll interaction set. A `MutationObserver`
+records attribute, text, insertion, and removal mutations, including old values
+where the platform exposes them. Open shadow roots present at startup or found
+in inserted nodes are observed separately; composed events are deduplicated.
+
+Input values, node markup/text, and text-bearing event details are excluded by
+default. Password/autocomplete-password fields and elements beneath
+`data-arcane-private` stay redacted even when ordinary value capture is enabled.
+Keyboard text, composition/input `data`, arbitrary `detail`, and clipboard
+contents are not retained by the safe defaults. Mutation `value`, `srcdoc`,
+style, credential-like attributes, and every URL-bearing attribute are replaced
+with markers; the observed document URL is never retained. Raw added/removed
+node markup is replaced with a content-omitted marker unless
+`captureNodeMarkup: true` is explicitly selected. Event payload keys that look
+like credentials, tokens, cookies, passwords, secrets, or private keys are also
+redacted before history or export.
+
+`captureInputValues`, `captureEventDetails`, `captureNodeMarkup`, and
+`captureStacks` are separate, explicit diagnostic choices. They remain bounded,
+and private targets plus URL fields remain protected, but any enabled diagnostic
+content may still be sensitive. Treat recordings as local evidence and review
+them before sharing.
+
+Mutation observation is an audit backstop, not proof of every renderer state
+change. It cannot see closed shadow roots, cross-origin frames, external web
+content, CSSOM/canvas drawing, most property-only writes, native/kernel activity,
+or interactions that happened before instrumentation started. Use semantic
+`instrument()` events at SDK-owned mutation boundaries when exact intent and
+causation matter.
+
+## Seek and playback
+
+`seek(sequence)` moves the diagnostic review cursor and emits
+`arcane.time-travel.seek`. It does not rewrite live DOM or application state.
+The safe default playback mode emits each immutable record on
+`arcane.time-travel.playback.record` for a debugger or review UI:
+
+```javascript
+events.on(PLAYBACK_RECORD_EVENT,record=>reviewTimeline(record));
+await events.playback({stack:serialized,mode:'review',speed:2});
+```
+
+`speed: 0` plays immediately; a positive value preserves monotonic recorded
+delays at that multiplier. Playback supports `AbortSignal` and emits an explicit
+completed, cancelled, or failed terminal event. Recording is suppressed during
+playback so replay cannot recursively add itself to the stack.
+
+`mode: 'events'` redispatches recorded event payloads to live subscribers. That
+mode can execute application effects and is only appropriate inside an isolated
+diagnostic harness with effectful subscribers replaced. The SDK does not
+synthesize trusted browser input, restore a prior DOM snapshot, resend native
+RPC, repeat provisioning, launch processes, write storage, or repeat network or
+other privileged effects.
+
+## Browser delivery boundary
+
+The package entry point works directly in Node and through browser bundlers.
+The npm artifact bundles the exact `event-pubsub` and `strong-type` pair because
+`event-pubsub@6.1.0` uses a sibling-relative runtime import. Unbundled browser
+use must preserve that physical sibling layout and provide import-map entries
+for the public SDK entry and `event-pubsub`.
+
+The current `0.1.0-dev.5` hash-pinned Arcane browser runtime does not yet
+bootstrap or package this SDK-authored module. Built-in Shell, Provisioner, and
+native Arcane application instrumentation therefore belongs in the downstream
+Arcane OS integration work; this SDK release does not claim automatic coverage
+inside those surfaces.

package/docs/platform-targets.md

@@ -0,0 +1,108 @@
+# Platform target contract
+
+Every target adapter implements protocol `arcane-target-adapter/1` with these
+named operations:
+
+```text
+describe -> doctor -> prepare -> plan -> build -> verify -> run
+```
+
+The available browser adapter plans from the selected workspace and schema-1
+release manifest. The SDK also implements the process-local
+`arcane-native-build-plan/1` and `arcane-native-builder/1` boundary for an
+explicitly injected provider. It binds an authenticated app release and
+schema-2 descriptor, toolchain receipt, platform, architecture, format, signing
+mode and identity, declared dependency releases, and destination. A paired
+provider must verify the built artifact before build completion, and verify/run
+reuse that exact artifact receipt.
+
+Native targets are available by explicitly pairing the SDK with fixed provider
+modules in a compatible Arcane OS checkout. Every native request also requires
+the canonical app descriptor to declare the exact target selected on the
+command line. The SDK package does not silently search for a toolchain, infer a
+descriptor target, embed the Arcane machine bundle, or substitute browser
+output. For example:
+
+```bash
+# Choose one target when creating each app repository.
+npx arcane-os@dev new my-app --path ./my-app --target portable --git
+cd my-app
+npm install
+npm exec -- arcane native-doctor --target portable --arcane-root "../Arcane OS"
+npm exec -- arcane build --target portable --arcane-root "../Arcane OS"
+
+# In an app scaffolded with --target windows-x64:
+npm exec -- arcane build --target windows-x64 --arcane-root "../Arcane OS"
+npm exec -- arcane run --target windows-x64 --arcane-root "../Arcane OS"
+
+# In an app scaffolded with --target linux-x64:
+npm exec -- arcane build --target linux-x64 --arcane-root "../Arcane OS"
+npm exec -- arcane run --target linux-x64 --arcane-root "../Arcane OS"
+
+# In an app scaffolded with --target linux-arm64, on native ARM64 Linux:
+npm exec -- arcane native-doctor --target linux-arm64 --arcane-root "../Arcane OS" --format deb --signing unsigned-local-test
+npm exec -- arcane build --target linux-arm64 --arcane-root "../Arcane OS" --format deb --signing unsigned-local-test
+npm exec -- arcane run --target linux-arm64 --arcane-root "../Arcane OS" --format deb --signing unsigned-local-test
+
+# In an app scaffolded with --target android-arm64. The run command requires
+# one connected physical Android device with native ARM64 support:
+npm exec -- arcane native-doctor --target android-arm64 --arcane-root "../Arcane OS" --format apk --signing development
+npm exec -- arcane build --target android-arm64 --arcane-root "../Arcane OS" --format apk --signing development
+npm exec -- arcane run --target android-arm64 --arcane-root "../Arcane OS" --format apk --signing development
+```
+
+Every native scaffold also declares the browser target, so one repository can
+use the normal browser development loop and its one selected native build. It
+includes the raster icon required by current Arcane native admission. Use the
+matching scaffold target (`portable`, `windows-x64`, `linux-x64`, `linux-arm64`,
+or `android-arm64`) before running the corresponding command.
+
+`native-prepare` remains a standalone integrity diagnostic. A receipt cannot be
+carried through a later CLI process, so the normal build recipe omits it and
+lets `build` prepare and reuse one exact toolchain state.
+
+The portable output is a verified app-scoped Arcane Core directory. It is an explicit
+portable builder payload, not an executable, and it has no direct run operation.
+The external workspace defaults to `build/portable/`; integrated Arcane work
+must use the same canonical checkout for `--workspace` and `--arcane-root`, and
+must name an `--output-root` outside that checkout.
+
+Compatibility uses the highest minimum Core version declared by the SDK runtime,
+selected app, and bundled app dependencies, plus each app's Arcane protocol and
+required features, capabilities, and methods. Newer Core versions are accepted
+when those contracts remain available. See [compatibility.md](compatibility.md)
+for the complete admission and breaking-change rule.
+
+| Target | Formats | Development status |
+|---|---|---|
+| `browser` | `directory` | Available |
+| `portable` | `portable` directory | Available with explicit `--arcane-root`; verified, not executable |
+| `windows-x64` | `exe` bundle | Available with explicit `--arcane-root`; unsigned local development only |
+| `linux-x64` | `deb` | Available with explicit `--arcane-root`; unsigned local development only |
+| `linux-arm64` | `deb` | Available with explicit `--arcane-root` on a compatible native ARM64 toolchain; unsigned local development only |
+| `android-arm64` | `apk` | Available with explicit `--arcane-root`; development-signed, architecture-neutral, and physical/native ARM64 for run |
+
+Every native target accepts one verified app release and its exact bundled
+dependency closure through the provider boundary. The providers retain the
+toolchain and artifact authority required for same-process verification and,
+where supported, launch; app source and workspace paths are not supplied to the
+provider. Linux run extracts to a user-owned development tree without package
+installation or elevation.
+
+Linux ARM64 uses the implemented Linux provider and is available only with a
+compatible native ARM64 toolchain. The target-scoped workflow at Arcane revision
+`4382043c09285ea203aa6daba1732660966ac409` built and retained-verified a native
+ARM64 DEB, proved AArch64 host/Core/bridge identities, reached WebKit readiness,
+and drained the owned process group. It loaded Ubuntu's packaged Bubblewrap
+AppArmor profile while leaving the global user-namespace restriction enabled.
+Android produces one development-signed APK with no native library or
+ABI-specific payload. The APK is therefore architecture-neutral, while
+`arcane run --target android-arm64` deliberately requires a physical device
+with native ARM64 support. The hardened path has exact-SHA physical ARM64/API 37
+build, readiness, cancellation, uninstall, and absence evidence. Both records
+are development evidence, not production readiness.
+
+Android AAB output, release signing, store publishing, and update continuity are
+deferred. Windows and Linux production signing, installation, and update
+acceptance also remain separate promotion work. The SDK never copies
+proprietary application source into the Arcane checkout to bypass the boundary.