launcher-next/docs/architecture/package-activation.md

Package activation

Files are copied to an operation-owned staging directory, rehashed and moved to a deterministic immutable version location. Materialization never changes activation pointers. Explicit activation writes schema-v2 current.json through an operation-owned temporary file, flush, replace and readback. The pointer binds manifest SHA-256, deterministic payload-set SHA-256 and every payload relative path/length/SHA-256.

Activation and receipt-bound rollback are serialized by a process-local SemaphoreSlim. Cross-process coordination is not verified and network-share pointer mutation is not supported. The controlled lifecycle pilot uses only an explicit local root and does not imply corporate DFS, AutoCAD runtime or production acceptance.

Rollback restores the exact pointers, deletes the pilot version and startup script, and removes incomplete staging. Autodesk assemblies, PDBs, executables, test assemblies and legacy files are rejected from the pilot package.

Last-known-good resolution

Each activated version retains its validated package manifest alongside its payload. PackageResolutionUseCase receives an explicit roster requirement: package ID, product/year/architecture, channel, exact version, roster identity and offline policy. On an online acquisition it stages locally, binds that requirement to the immutable version, then revalidates through LocalPackageStore.ResolveAsync.

The resolver checks manifest, binding, identity/product compatibility, entry and all payload lengths/SHA-256 before returning a local version. It returns current first. Only when current is invalid and the requirement explicitly permits offline fallback can it return previous. A cache entry with another roster, channel or version is rejected. It never reads or executes a package from DFS, and a failed or corrupted update never becomes last-known-good. Resolution follows only the explicit current/previous pointers and never enumerates the version store to find an approximate candidate.

Resolution emits stable evidence codes: ONLINE_PACKAGE_SELECTED, VALID_CURRENT_CACHE_SELECTED, PREVIOUS_LKG_SELECTED, OFFLINE_FALLBACK_DISABLED, and NO_SAFE_PACKAGE_AVAILABLE.

Roster-to-package plan

RosterAdapter keeps source formats outside the package domain. It selects, in order, a project roster.json, a legacy download_list.xml, then an explicit central default; malformed project JSON is a block, not an implicit fallback. JSON roster version 1 requires a stable roster ID, product, year, architecture, explicit offline policy and unique package IDs. Legacy XML disables DTD/external entities and accepts only proven Plugin fields (id, version, optional channel and install).

RosterPackagePlanUseCase converts enabled records into deterministic, load-order-sorted requirements and resolves every one before launch preparation. It emits roster/source, requirement and plan-completed/blocked evidence. The filesystem catalog adapter returns a descriptor for acquisition only; local immutable staging remains the only active package root. These adapters and the controlled local catalog scenarios are verified by tests; a corporate DFS pilot and Autodesk launch with a real roster are not runtime verified.

Catalog acquisition is bounded before staging: the configured catalog root and package root must not be reparse points, the descriptor must remain below the configured root, manifests may contain at most 256 files and 512 MiB declared payload, and absolute or traversal payload paths are rejected. A corporate pilot requires explicit configured roster and catalog roles; absent roles block before any corporate payload is read.