docs: lock v1 scope and terminology

README.md

@@ -154,12 +154,46 @@ Reserved rule: `builtin`
 
 ---
 
+## Shared Terminology
+
+To keep the umbrella repo, protocol repo, and both plugin repos aligned, Yonexus uses these terms consistently:
+
+- `identifier`: the stable logical name of a follower/client instance, unique within one Yonexus network.
+- `rule_identifier`: the exact-match application routing key used in `${rule_identifier}::${message_content}`.
+- `builtin`: the reserved rule namespace for Yonexus protocol/control messages only.
+- `pairingCode`: the short-lived out-of-band code generated by `Yonexus.Server` and delivered to a human admin by Discord DM.
+- `secret`: the server-issued shared secret established after successful pairing and used in reconnect authentication proof construction.
+- `publicKey` / `privateKey`: the client-owned signing keypair used for auth proof signing and verification.
+- `nextAction`: the server decision returned in `hello_ack`, currently one of `pair_required`, `waiting_pair_confirm`, `auth_required`, or `rejected`.
+
+## v1 Scope Boundaries
+
+In scope for v1:
+- WebSocket transport between one server and one or more clients
+- out-of-band pairing via Discord DM to a human administrator
+- signed reconnect authentication using `secret + nonce + timestamp`
+- heartbeat/liveness tracking (`online | unstable | offline`)
+- exact-match rule dispatch
+- lightweight persistence for trust/state material
+- optional `heartbeat_ack`
+- exponential reconnect backoff on the client side
+
+Explicitly out of scope for v1:
+- multi-server topology
+- direct client-to-client sockets
+- offline message queues / delivery guarantees
+- advanced rule matching (prefix/regex/wildcard)
+- management UI
+- distributed consensus / clustering
+- automatic admin approve/deny workflows beyond human relay of the pairing code
+- encryption-at-rest hardening beyond documenting local sensitive storage behavior
+
 ## Status
 
-- planning/specification stage
-- split-plugin architecture defined
-- protocol draft defined in `Yonexus.Protocol`
-- implementation not started yet
+- umbrella/specification repo is aligned with the split architecture
+- core implementation work is underway in `Yonexus.Server`, `Yonexus.Client`, and `Yonexus.Protocol`
+- protocol/types/codec/test scaffolding already exists in `Yonexus.Protocol`
+- runtime, transport, pairing, auth, heartbeat, rule dispatch, and test coverage are largely implemented in submodules; remaining work is focused on boundary cleanup and leftover failure-path coverage
 
 ---