NEXT temporary contract 3.15 — Transaction domains and Arch interoperability

01Temporary normative staging unit. Its body is the accepted architecture from refined plan revision 4, section 3.15. Before production code cites this law, promote the relevant clauses into permanent specifications. This file is consumed only after semantic coverage, implemented behavior and retained evidence are accepted. The task/retirement checker cannot perform semantic acceptance.

02Recommendation pending D-022: first coexist with pacman; Vibe owns environment intent and Vibe payloads, pacman/libalpm owns Arch package selection, database and files. Later replacing the pacman UI through libalpm and replacing the entire Arch backend are different projects. The generic backend port allows either without changing environment manifests into shell scripts.

03Backend interface: capabilities, prepared catalog/installed snapshot, resolve with native version semantics, fetch exact artifacts, proposed transaction/footprint, apply against checked DB generation, observe/verify/recover. Package-defined implementation uses existing registry/provider model and versioned wires. A native planning call is trusted execution in explicit preparation; pure plan/inspect consumes its captured result. No parsing of human progress prose as authority; use library API or bounded machine outputs with independent post-state validation. CLI facade choice does not define core schema.

04Each backend retains sole authority over its domain. Vibe records external roots, snapshot/config/verification policy and resolved closure evidence, not a second writable copy of pacman's installed DB. Foreign solver runs on a frozen catalog/current-state capture. Changed resolver/DB result requires a new prepared plan; apply never silently re-resolves latest after approval. Vibe-owned packages may require external capabilities; cross-domain dependencies must be explicit acyclic backend requests or a proven joint solver boundary. Do not invent a blind retry loop or translate foreign provides/conflicts into lossy Vibe strings.

05Whole Arch update is a coherent repository epoch operation. Record repository order/snapshot, architecture, package bytes/digests and backend verification policy; partial upgrades are not a supported Arch strategy. Existing external trust requirements remain in force: D-011 optional Vibe receipt signatures does not mean disabling Arch package signatures/key trust. Installing a wrapper cannot self-enroll repository trust. See E35–E37.

06Installation into a directory is not arbitrary relocation. Arch guest-root operations must bind root, DB, config, cache/keyring and hook execution to the intended Linux environment; pacman --root is not a general HOME installer, and mounted guest operation has distinct --sysroot semantics (E35). M-15 executes the backend in a disposable Linux build target; it does not operate on the developer's live host system.

07There is no atomic transaction across a foreign package engine, Vibe activation and external services. Plan partitions effects into domains with ordered prerequisites, retained before-state where possible, journaled completion and typed recovery status. Vibe-owned profile generation can switch atomically only on a supporting filesystem and within that activation pointer; config edits/services/hooks remain separate recorded effects. Arbitrary post-install hooks are not reversible by deleting installed files. Interrupted foreign apply may require backend repair or rebuilding an offline image; it must not be labelled rolled-back/successful.

08One file/resource has one physical authority. Vibe avoids pacman-owned paths unless an explicit integration contract delegates a configuration resource or adoption transfers ownership. Equal bytes never transfer ownership. Writing Vibe-owned snippets in an allowed directory can coexist with backend-owned base config; overwriting backend files with a blanket overwrite flag cannot. Preserve modified user config on update/removal, offer explicit conflict disposition, retain mutable data independently of package state. Database/service data migration is a separate operation with its own rollback truth.

09Operation authority is target/effect-bound and revalidated, including current principal, mounts/root identity and environment generation. Installation can grant its complete reviewed declared operation without repeated confirmations. It does not authorize arbitrary home/root/network effects; root privilege inside a Linux builder does not grant root on the host. Existing system privilege enum is metadata, not an elevation broker. Live system support later uses explicit OS-supported elevation for the exact admitted operation; no blanket sudo, credential collection or assumption that native code is confined by a Rust type.