4.1 KiB
4.1 KiB
Yonexus.Server — Development Conventions
This document defines implementation conventions for the server repository.
1. Naming Conventions
Files
- use
camelCase.tsfor source files - use descriptive module names matching responsibility
- avoid generic names like
utils.tsunless the scope is extremely narrow and justified
Examples:
registry.tspairing.tsheartbeat.tsonGatewayStart.ts
Types / Interfaces
- use
PascalCase
Examples:
ClientRecordPairingStateServerRuntime
Functions
- use
camelCase
Examples:
loadRegistryverifyAuthProofsendPairingNotification
Constants
- use
UPPER_SNAKE_CASEfor exported constants
Examples:
HEARTBEAT_INTERVAL_MSAUTH_WINDOW_SECONDS
2. Module Boundaries
plugin/index.ts
- wiring only
- no business logic
plugin/core/
- reusable domain logic
- state transitions
- validation
- auth/pairing/heartbeat rules
servers/
- network/runtime bootstrapping
- WebSocket transport lifecycle
- active connection management
plugin/hooks/
- OpenClaw lifecycle integration
- should call into core/runtime modules, not reimplement logic
plugin/tools/
- thin wrappers over core/runtime capabilities
- do not duplicate business rules already implemented in core
plugin/commands/
- operator-facing orchestration layer
- no core logic duplication
3. Error Conventions
Error Shape
Use structured errors rather than throwing untyped strings.
Recommended shape:
interface YonexusServerError extends Error {
code: string;
details?: Record<string, unknown>;
}
Error Code Style
- uppercase snake case
- stable once published in logs/tools/docs
Examples:
INVALID_CONFIGIDENTIFIER_NOT_ALLOWEDPAIRING_EXPIREDNONCE_COLLISION
Error Messages
- concise
- operator-readable
- do not leak secrets, tokens, raw proofs, or private internal state
4. Logging Conventions
General Rule
Logs should be useful for operators and safe for production.
Must Never Log in Plaintext
notifyBotToken- client
secret - raw pairing code after issuance
- raw signed proof payload
- any private key material
Preferred Log Fields
When possible, log structured context such as:
identifier- event type
- status transition
- reason code
- timestamp
Example Good Logs
pairing started for identifier=client-aauth failed for identifier=client-a reason=NONCE_COLLISIONstatus changed identifier=client-a online->unstable
5. Protocol Usage Conventions
- treat
protocol/submodule as the source of truth - do not fork protocol semantics locally without updating
Yonexus.Protocol - if implementation pressure suggests protocol change, change protocol repo first or in the same coordinated step
6. Persistence Conventions
- prefer explicit versionable JSON structures for initial persistence
- keep persisted schema clear and documented
- do not mix transient socket/session state into long-lived persisted records unless intentional
- keep rolling replay/rate-limit windows separate from durable trust records where practical
7. State Machine Conventions
- keep state transitions explicit
- avoid hidden/implicit mutations across unrelated modules
- centralize transitions for pairing/auth/liveness when possible
- treat
re_pair_requiredas a first-class transition, not an ad-hoc side effect
8. Command / Tool Conventions
- commands and tools should surface operator-safe summaries
- raw internal state should be exposed carefully
- commands should call core/runtime services, not manipulate registry internals directly
9. Testing Conventions
- write narrow unit tests for deterministic logic first
- reserve integration tests for protocol flow and socket lifecycle
- test negative paths deliberately:
- invalid pairing code
- stale timestamp
- nonce collision
- excessive handshake attempts
- heartbeat timeout
10. Change Discipline
When implementing:
- update docs when architecture/protocol behavior changes
- avoid silent divergence from
PLAN.md,TASKS.md, andprotocol/PROTOCOL.md - prefer fewer clear modules over many shallow wrappers