# QNE Cross-Platform Device Vault Doctrine V1

Status: current operational doctrine
Date: 2026-05-24
Workspace anchor: qne-v225

## Relationship to QNE Doctrine Archive

This document is a current working addition to the QNE doctrine set. It is a Layer B current support doctrine under the archived canonical doctrine map.

It extends the installer/PA-first doctrine by defining how QNE device secrets should be held on Linux, Windows, macOS, and later mobile devices.

## Core Rule

A QNE device is not trusted because it has a copied secrets file. It is trusted because its local OS vault can unlock its own encrypted QNE persist/secrets.

Do not copy a founder master key between devices.

## Device Vault Model

Each QNE-capable device has:

- local QNE persist/secrets records;
- a device-local QNE master key stored in the platform OS vault;
- QNE tools that ask the OS vault to unlock the local encrypted persist/secrets;
- no raw secret values stored in plain files.

Platform vault backends:

- Linux: Secret Service/keyring.
- Windows: Windows Credential Manager or DPAPI through the QNE vault abstraction.
- macOS: Keychain through the QNE vault abstraction.
- Mobile later: the platform secure store/keychain.

## Home Directory Root Doctrine

QNE roots should live under the user's home/profile directory on every desktop platform.

Linux and macOS:

- `~/QNE`
- `~/QNE-keep`
- `~/QNE-developer`
- `~/QNEDEV`

Windows:

- `%USERPROFILE%\QNE`
- `%USERPROFILE%\QNE-keep`
- `%USERPROFILE%\QNE-developer`
- `%USERPROFILE%\QNEDEV`

Avoid `Program Files`, system roots, and admin-required locations for the normal QNE member path.

## Developer Exchange Secret Class

`dev_exchange_storage` is a distinct secret class used for cross-device developer handoff exchange.

It may include narrowly scoped storage credentials such as:

- `dev_exchange_storage.endpoint`
- `dev_exchange_storage.access_key`
- `dev_exchange_storage.refresh_token`
- `dev_exchange_storage.bucket_or_folder`

It must not include:

- founder deployment secrets;
- Bunny/Namecheap administration keys unless explicitly scoped for that device and role;
- copied Linux founder vault master keys;
- raw public member persist state outside an intentional handoff bundle.

## Developer Device Enrollment

A Windows/macOS developer device should be enrolled as its own QNE developer device:

1. Create the platform home roots.
2. Create `QNE-developer/persist`.
3. Initialize a local QNE master key in that device's OS vault.
4. Add only the minimum `dev_exchange_storage` credentials needed for artifact exchange.
5. Use QNE online storage tooling to pull handoff zips and push return zips.

The founder Linux device remains the publishing and deployment authority until that authority is explicitly delegated.

## Developer Installer

Developer installers may be downloaded from `qne.info`, but they must not contain founder secrets, deployment keys, copied OS-vault master keys, or raw persist/secrets files.

The developer installer should:

- create the platform home/profile QNE roots;
- install QNE-owned developer tools under `QNE-developer/repository/tools`;
- initialize the local device OS vault through the QNE vault path;
- initialize encrypted developer persist/secrets under `QNE-developer/persist`;
- enroll `dev_exchange_storage` only from an explicit one-time enrollment bundle or operator-entered credential;
- fetch and unpack handoff/context zips only after local vault and encrypted persist/secrets are initialized.

Enrollment bundle encryption must not rely on a four-digit PIN alone. The QNE developer PIN is a human unlock factor and must be combined with a separate high-entropy enrollment key, using Argon2id before decrypting the enrollment payload.

## Implementation Direction

The `qne-vault-tool` should be the single QNE-owned vault interface used by persist/secrets tooling.

One perceived vault operation should go through one shared QNE vault path. Do not duplicate Credential Manager, Keychain, Secret Service, DPAPI, or mobile secure-store logic in separate tools or UI components.
