# QNE Installer PA-First Doctrine V1

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

## Relationship to QNE Doctrine Archive

This document is a current working addition to the QNE doctrine set. It does not replace the archived canonical doctrine bundles under `/home/paulf/QNEDEV/archive/project-zips`.

It should be read as a Layer B current support doctrine under the older canonical map:

- Layer A remains the latest canonical doctrine truth and master doctrine indexes.
- Layer B contains current support material, runbooks, workflow doctrine, and operational doctrine.
- Layer C remains historical/reference material.
- Layer D remains tool, self, project, and implementation internals.

This doctrine records the current public installer and first-run experience discovered during qne-v225 Linux installer work.

## Core Product Principle

The public QNE installer is infrastructure, not the first user experience.

The first visible user experience should be QNE itself, opening directly into the PA window and starting the first conversation. A conventional installer wizard should not be the normal public path unless a later platform requires one.

## Public Member Install Doctrine

The normal public install path is:

1. A person downloads the QNE AppImage from `qne.info`.
2. The person double-clicks the AppImage.
3. QNE installs quietly under `~/QNE`.
4. If `~/QNE-keep/qne-persist-latest.zip` exists, QNE restores that persist bundle into the new `~/QNE/persist`.
5. If `~/QNE-keep` does not exist, QNE creates a fresh public member instance under `~/QNE`.
6. QNE creates desktop/menu integration.
7. QNE opens directly into the PA window.
8. The PA starts the first conversation.

The installer should avoid unnecessary questions. The PA should handle explanation, orientation, consent, recovery, setup, and next actions conversationally.

## First Conversation Doctrine

The first visible QNE screen should be the PA conversation. The PA should eventually be able to:

- welcome the member;
- explain that QNE has installed locally under `~/QNE`;
- detect and explain whether a previous `~/QNE-keep` recovery bundle was restored;
- distinguish a new member path from a returning member path;
- help the member understand local custody, recovery, and community participation;
- continue into onboarding without exposing installer mechanics as the primary experience.

## Uninstall And Rejoin Doctrine

Leaving QNE should also become a PA conversation.

The preferred future user path is:

1. The member tells the PA they want to leave QNE.
2. The PA explains that QNE can preserve a return bundle under `~/QNE-keep`.
3. The PA asks for clear confirmation.
4. QNE closes the node, writes a persist zip into `~/QNE-keep`, removes desktop/menu integration, removes the installed app root `~/QNE`, and leaves the keep bundle behind.
5. If the member later reinstalls QNE, the installer detects `~/QNE-keep` and restores the member's state.

The command-line uninstall remains a support/admin fallback.

## Root Separation Doctrine

Public member install roots:

- `~/QNE` is the normal public member install root on Linux and macOS.
- `%USERPROFILE%\QNE` is the normal public member install root on Windows.
- `~/QNE-keep` is the normal public member recovery handoff root on Linux and macOS.
- `%USERPROFILE%\QNE-keep` is the normal public member recovery handoff root on Windows.

Founder/developer roots:

- `~/QNE-developer` is the founder/developer operational root on Linux and macOS.
- `%USERPROFILE%\QNE-developer` is the founder/developer operational root on Windows.
- `QNE-developer/persist` stores founder/developer operational persist state.
- `QNE-developer/repository/tools` stores founder/developer reusable operational tools.
- `QNE-developer` may contain third-party operational secrets needed for deployment and administration.

Development source root:

- `~/QNEDEV` is the development source, archive, and workspace root on Linux and macOS.
- `%USERPROFILE%\QNEDEV` is the development source, archive, and workspace root on Windows.

Public downloaded installs must not depend on founder/developer third-party secrets. Bunny, Namecheap, CDN, deployment, and registry operations belong to the founder/developer operational root, not the public member install root.

## Installer Behavior Doctrine

The public installer should be self-contained for the current packaged QNE payload. It should not download QNE application binaries during install.

The public installer should:

- install from its own packaged payload;
- use `~/QNE` for the public member installation;
- create or restore `~/QNE/persist`;
- use `~/QNE-keep` only as a public member recovery handoff;
- create desktop/menu integration by default;
- launch QNE after a no-argument double-click install;
- leave the member inside the QNE PA experience, not inside installer UI.

The public uninstaller should:

- stop QNE if running;
- preserve `~/QNE/persist` into `~/QNE-keep/qne-persist-<timestamp>.zip` when persist exists;
- update `~/QNE-keep/qne-persist-latest.zip`;
- remove desktop/menu/icon/service integration;
- remove `~/QNE` completely.

## Implementation Notes From qne-v225

The qne-v225 Linux installer established this practical behavior:

- The AppImage is less than 12 MB.
- The install step is local and self-contained for the current QNE payload.
- Double-click install can create `~/QNE`, create menu integration, and open QNE immediately.
- `~/QNE-developer` separates founder/developer operations from public member installs.
- `qne.info` serves the current public Linux AppImage.

This doctrine should guide the next implementation stage: the launched QNE window should land in a PA-first onboarding state.
