# qne-node-v00616 Agent Rules

This project follows the QNE master rules in `~/QNE-doctrine/qnerules.md`.
This file is the reduced project-specific rule set for `qne-node-v00616`.

## Version Rule

Do not publish fixes under the same version. Durable changes after v00616 is
published must create `qne-node-v00616` or the next appropriate project version.

## QNE Source Authority Rule

Do not propose or document external source-control workflows for this project.
QNE project authority is source code plus current doctrine packaged as QNE
source zips, stored and transferred through QNE-approved storage and publishing
tools.

## Rust-First Rule

Operational automation belongs in Rust. Do not add Bash, PowerShell, or batch
installer logic except tiny unavoidable OS bridges. Installer behavior belongs
in `qne-installer`.

## Real Base Node Rule

`qne-node-v00616` is the first minimal version of the permanent QNE node
runtime. Do not treat it as a throwaway bootstrap node. A full user install adds
the separate UI crate/app, user onboarding, and user-facing qneskills on top of
the same node runtime.

Heartbeat/presence behavior is a real current qneskill:
`qneskill-node-presence-v00616`. Heartbeat/liveness traffic is only needed when
no other qneskill data has moved across a session during the liveness interval.

Role-specific node abilities must be provisioned through the current
`qneskill-role-manifest-v00616` skill. The skill repository role serves manifests
for master, seed, skill repository, Linux builder, Windows builder, founder, and
general development nodes.

Presence cache behavior is current, bounded behavior. A normal node must store
only its own current presence, active/recent contact presence, relevant scoped
records, and a bounded gossip cache. Do not add unbounded known-node storage.
User nicknames/contact aliases do not belong in node presence.

Gossip is qneskill record sync over qne-p2p. Do not add a separate gossip
transport.

Installer downloads must be coordinated by the master before Bunny serves the
large file. Treat MaxMind ASN/ISP/GeoNames data as temporary bootstrap hints,
not identity. Keep download session records short-lived. Use one bootstrap UUID
for the base install; after claim it is the qne-node UUID.

A base qne-node install creates only a node. Do not create user UUIDs, base36
user names, or user actor directories during qne-node installation. Users are
created later by node/user-onboarding flows, and some qne-nodes will never have
users.

Every persist root must be structurally complete from creation with `lmdb/`,
`ltr/`, and `secrets/`, even when the current version does not use all three.
Skills and customization may rely on these directories existing.

Hetzner development role customization is installer-profile based, not a
different node runtime. Use:

- `qne-installer install --profile development-master`
- `qne-installer install --profile development-seed-master`
- `qne-installer install --profile development-skill-repo`

The profiles set the node name and service role. Role-specific behavior must
still come through role qneskills.

P2P transport must always use the black-box `qne-p2p` dependency. Do not add
raw UDP transport, custom handshakes, custom p2p framing, or replacement p2p
session logic in `qne-node` or qneskills. If `qne-p2p` appears to need changes,
refer the needed change to the founder before editing the p2p crate.

## Development Network

Use:

- network id `qne-development-network`
- `development-master-0001`
- `development-seed-master-0001`
- `development-skill-repo-0001`
- 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`

The first milestone is node-only. Do not add user IDs or `users/<base36>` node
behavior in this version.

## Install Layout

Use:

- `~/QNE/qne-node/persist`
- `~/QNE/runtimes/qne-node-v00616`
- `~/QNE/users`
- `~/QNE/logs`

## Codex Boundary

Codex presence may be checked, but do not copy, sync, back up, or transmit
Codex `auth.json`, refresh tokens, API keys, Pro credentials, or browser login
sessions.

## Tool Repository

Developer tools are platform-specific under
`~/QNE-developer/repository/tools/<platform>/`. Use the current platform's tool
directory and update `TOOL-MANIFEST.tsv` when tool binaries change.

## Doctrine Promotion

If this project creates new durable doctrine, update `~/QNE-doctrine/qnerules.md`
or a routed file under `~/QNE-doctrine/current/`, then upload the verified
doctrine tree to encrypted online storage.
