# qne-node-v00616

Fresh QNE base node for the development network.

This version is the first minimal version of the permanent QNE node runtime. It
does not carry forward the v580/v590 application stack, but it is not temporary
scaffolding. Its job is to install as a service, create local node state, run
the node-presence qneskill over the black-box `qne-p2p` dependency, talk to the
development Hetzner system peers, and provide the runtime surface that later UI,
user onboarding, qneskills, and Codex workers can extend. QNE peer-to-peer
transport must not be reimplemented in this node.

v00616 also runs the current `qneskill-role-manifest-v00616` skill. Nodes ask
`development-skill-repo-0001` for the manifest for their startup role, store it
under `qne-node/persist/skills/active-role-manifest.json`, and advertise the
returned active qneskills in presence.

v00616 adds the first bounded presence cache. Presence records are the current,
safer form of known-node entries: fresh node-level endpoint/capability hints,
not user contact aliases. Normal nodes keep only their own current presence,
recent/relevant peer presence, and a bounded gossip cache. The current cache
limits are 5000 records, 32 MB, 24 hour max age, and 15 minute presence TTL.
Records are marked unsigned until qne-p2p exposes a stable static-key identity
and signing API.

v00616 also adds the first master-coordinated download-session foundation. The
new `qne-download-coordinator` Rust binary creates short-lived bootstrap records
for installer downloads: platform guess, requester IP observation, optional
MaxMind ASN/ISP/GeoNames hints, Bunny artifact URL, nonce hash, and one
bootstrap UUID. When claimed, that bootstrap UUID becomes the qne-node UUID.
Bunny remains the large-file host. The coordinator is currently a file-backed
command-line foundation, not a public HTTP service.

Base installation creates only a qne-node. It does not create users, user UUIDs,
base36 user names, or user actor directories beyond the empty `users` workspace
directory.

Development system peers:

- `development-master-0001`: network authority/master coordination
- `development-seed-master-0001`: stable seed and DHT discovery entry point
- `development-skill-repo-0001`: day-one skill/project zip authority

Default contacts:

- `development-master-0001 [2a01:4f9:c015:4e9b::1]:7001`
- `development-seed-master-0001 [2a01:4f9:c010:dc18::1]:7001`
- `development-skill-repo-0001 [2a01:4f9:c014:c173::1]:7001`

## Local layout

The dev-network install root is the signed-in user's QNE workspace:

```text
~/QNE/
  qne-node/
    persist/
      lmdb/
      ltr/
      secrets/
      presence/current.json
      gossip/records/
  users/
    <base36-user-name>/
      persist/
        lmdb/
        ltr/
        secrets/
  runtimes/
    qne-node-v00616/
      bin/qne-node
  logs/
```

`qne-node` is the device/node actor and lives at the same level as `users`.
Each user actor later gets its own base36 subdirectory under `users`, with its
own `persist` below it. Runtime versions are replaceable packages under
`runtimes`; node and user persist data should not live inside a runtime version.
Every persist root is structurally complete from creation with `lmdb`, `ltr`,
and `secrets`, even if a given version has not started using every part yet.

## Build

```sh
cargo test
cargo build --release
```

## Run a node

```sh
cargo run -p qne-node -- init --home ./tmp/QNE/qne-node/persist
cargo run -p qne-node -- run --home ./tmp/QNE/qne-node/persist --once
cargo run -p qne-node -- role-manifest --role linux-builder-x86_64
cargo run -p qne-node -- role-manifest --role network-master
cargo run -p qne-installer -- detect-platform
cargo run -p qne-installer -- plan --platform linux --profile development-master --out ./artifacts/installers/development-master-linux
cargo run -p qne-installer -- plan --platform linux --profile development-seed-master --out ./artifacts/installers/development-seed-master-linux
cargo run -p qne-installer -- plan --platform linux --profile development-skill-repo --out ./artifacts/installers/development-skill-repo-linux
cargo run -p qne-download-coordinator -- create --cache-root ./tmp/master-cache --platform-guess macos-aarch64 --artifact-name qne-node-v00616-macos-arm64.zip --bunny-url https://qne.example/qne-node-v00616-macos-arm64.zip --requester-ip 203.0.113.7 --asn 64500 --isp example
cargo run -p qne-node -- init --home ./tmp/QNE/qne-node/persist --node-id <bootstrap-uuid>
```

## Build local installer payloads

```sh
cargo run -p qne-installer -- plan --platform macos --out ./artifacts/installers/macos
cargo run -p qne-installer -- plan --platform linux --out ./artifacts/installers/linux
cargo run -p qne-installer -- plan --platform windows --out ./artifacts/installers/windows
```

The installer crate writes platform service definitions and performs installs
from Rust. Real platform artifacts should be produced on the native platform
device or QNE builder node, then uploaded to Bunny.

The three Hetzner development roles are still the same base qne-node runtime.
Install them with profiles:

- `development-master`: node name `development-master-0001`, role `network-master`
- `development-seed-master`: node name `development-seed-master-0001`, role `master-seed`
- `development-skill-repo`: node name `development-skill-repo-0001`, role `master-skill-repository`

## Project zip rule

The source-authority project zip must stay rebuildable and small. Include source,
`Cargo.lock`, docs, `AGENTS.md`, and bundled doctrine. Exclude generated output:

```text
target/
artifacts/
```

Installer zips are separate download artifacts published to Bunny. They can be
rebuilt from the project source and should not be nested inside the project zip.
