- Add Microsoft.Extensions.Logging + Serilog to NatsServer and NatsClient - Convert all test assertions from xUnit Assert to Shouldly - Add NSubstitute package for future mocking needs - Introduce Central Package Management via Directory.Packages.props - Add documentation_rules.md with style guide, generation/update rules, component map - Generate 10 documentation files across 5 component folders (GettingStarted, Protocol, Subscriptions, Server, Configuration/Operations) - Update CLAUDE.md with logging, testing, porting, agent model, CPM, and documentation guidance
12 KiB
Documentation Rules
This document defines the documentation system for the NATS .NET server project. It provides guidelines for generating, updating, and maintaining project documentation.
The documentation is intended for internal team reference — explaining what the system is, how it works, how to extend it, and how to debug it.
Folder Structure
Documentation/
├── Instructions/ # Guidelines for LLMs (meta-documentation)
│ └── (this file serves as the single instructions reference)
│
├── GettingStarted/ # Onboarding, prerequisites, first run
├── Protocol/ # Wire protocol, parser, command types
├── Subscriptions/ # SubList trie, subject matching, wildcards
├── Server/ # NatsServer orchestrator, NatsClient handler
├── Configuration/ # NatsOptions, appsettings, CLI arguments
├── Operations/ # Deployment, monitoring, health checks, troubleshooting
└── Plans/ # Design documents and implementation plans
Future module folders (add as modules are ported):
├── Authentication/ # Auth mechanisms, NKeys, JWT, accounts
├── Clustering/ # Routes, gateways, leaf nodes
├── JetStream/ # Streams, consumers, storage, RAFT
├── Monitoring/ # HTTP endpoints (/varz, /connz, etc.)
├── WebSocket/ # WebSocket transport
└── TLS/ # TLS configuration and setup
Style Guide
Tone and Voice
- Technical and direct — no marketing language. Avoid "powerful", "robust", "seamless", "blazing fast".
- Assume the reader is a .NET developer — don't explain dependency injection, async/await, or LINQ basics.
- Explain "why" not just "what" — document reasoning behind patterns and decisions.
- Use present tense — "The parser reads..." not "The parser will read..."
Formatting Rules
| Aspect | Convention |
|---|---|
| File names | PascalCase.md |
H1 (#) |
Document title only, Title Case |
H2 (##) |
Major sections, Title Case |
H3+ (###) |
Subsections, Sentence case |
| Code blocks | Always specify language (csharp, json, bash, xml) |
| Code snippets | 5-25 lines typical; include class/method context |
| Cross-references | Relative paths: [See SubList](../Subscriptions/SubList.md) |
| Inline code | Backticks for code refs: NatsServer, SubList.Match(), NatsOptions |
| Lists | Bullets for unordered, numbers for sequential steps |
| Tables | For structured reference (config options, command formats) |
Naming Conventions
- Match code terminology exactly:
SubListnot "Subject List",NatsClientnot "NATS Client Handler" - Use backticks for all code references:
NatsParser,appsettings.json,dotnet test - Spell out acronyms on first use: "NATS Adaptive Edge Messaging (NATS)" — common acronyms that don't need expansion: API, JSON, TCP, HTTP, TLS, JWT
Code Snippet Guidelines
Do:
- Copy snippets from actual source files
- Include enough context (class name, method signature)
- Specify the language in code blocks
- Show 5-25 line examples
// Good — shows class context
public sealed class NatsServer : IMessageRouter, ISubListAccess, IDisposable
{
public async Task StartAsync(CancellationToken ct)
{
_listener = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
_listener.Bind(new IPEndPoint(IPAddress.Parse(_options.Host), _options.Port));
_listener.Listen(128);
}
}
Don't:
- Invent example code that doesn't exist in the codebase
- Include 100+ line dumps without explanation
- Use pseudocode when real code is available
- Omit the language specifier on code blocks
Structure Conventions
Every documentation file must include:
- Title and purpose — H1 heading with 1-2 sentence description
- Key concepts — if the topic requires background understanding
- Code examples — embedded snippets from actual codebase
- Configuration — if the component has configurable options
- Related documentation — links to related topics
Organize content from general to specific:
- Overview/introduction
- Key concepts
- Basic usage
- Advanced usage / internals
- Configuration
- Troubleshooting
- Related documentation
End each document with:
## Related Documentation
- [Related Topic](../Component/Topic.md)
What to Avoid
- Don't document the obvious (e.g., "The constructor creates a new instance")
- Don't duplicate source code comments — reference the file instead
- Don't include temporary information (dates, version numbers, "coming soon")
- Don't over-explain .NET basics
Generating Documentation
Document Types
Each component folder should contain these standard files:
| File | Purpose |
|---|---|
Overview.md |
What the component does, key concepts, architecture |
Development.md |
How to add/modify features, patterns to follow |
Configuration.md |
All configurable options with defaults and examples |
Troubleshooting.md |
Common issues, error messages, debugging steps |
Create additional topic-specific files as needed (e.g., Protocol/Parser.md, Subscriptions/SubList.md).
Generation Process
- Identify scope — which component folder does this belong to? (See Component Map below)
- Read source code — understand the current implementation, identify key classes/methods/patterns, note configuration options
- Check existing documentation — avoid duplication, cross-reference rather than repeat
- Write documentation — follow the style guide, use real code snippets
- Verify accuracy — confirm snippets match source, verify file paths and class names, test commands
Creating New Component Folders
- Create the folder under
Documentation/ - Add at minimum
Overview.md - Add other standard files as content warrants
- Update the Component Map section below
- Add cross-references from related documentation
Updating Documentation
Update Triggers
| Code Change | Update These Docs |
|---|---|
| New protocol command | Protocol/ relevant file |
| Parser modified | Protocol/Parser.md |
| Subject matching changed | Subscriptions/SubjectMatch.md |
| SubList trie modified | Subscriptions/SubList.md |
| New subscription type | Subscriptions/Overview.md |
| NatsServer changed | Server/Overview.md |
| NatsClient changed | Server/Client.md |
| Config option added/removed | Component's Configuration.md |
| NatsOptions changed | Configuration/Overview.md |
| Host startup changed | Operations/Deployment.md + Configuration/ |
| New test patterns | Corresponding component docs |
| Auth mechanism added | Authentication/ (create if needed) |
| Clustering added | Clustering/ (create if needed) |
Update Process
- Identify affected documentation — use the Component Map to determine which docs need updating
- Read current documentation — understand existing structure before making changes
- Make targeted updates — only modify sections affected by the code change; don't rewrite unaffected sections
- Update code snippets — if the code change affects documented examples, update them to match
- Update cross-references — add links to newly related docs, remove links to deleted content
- Add verification comment — at the bottom:
<!-- Last verified against codebase: YYYY-MM-DD -->
Deletion Handling
- When code is removed, remove corresponding doc sections
- When code is renamed, update all references (docs, snippets, cross-reference links)
- If an entire feature is removed, delete the doc file and update any index/overview docs
- Search all docs for links to removed content
What Not to Update
- Don't reformat documentation that wasn't affected by the code change
- Don't update examples that still work correctly
- Don't add new content unrelated to the code change
- Don't change writing style in unaffected sections
Component Map
Source to Documentation Mapping
| Source Path | Documentation Folder |
|---|---|
src/NATS.Server/Protocol/NatsParser.cs |
Protocol/ |
src/NATS.Server/Protocol/NatsProtocol.cs |
Protocol/ |
src/NATS.Server/Subscriptions/SubList.cs |
Subscriptions/ |
src/NATS.Server/Subscriptions/SubjectMatch.cs |
Subscriptions/ |
src/NATS.Server/Subscriptions/Subscription.cs |
Subscriptions/ |
src/NATS.Server/Subscriptions/SubListResult.cs |
Subscriptions/ |
src/NATS.Server/NatsServer.cs |
Server/ |
src/NATS.Server/NatsClient.cs |
Server/ |
src/NATS.Server/NatsOptions.cs |
Configuration/ |
src/NATS.Server.Host/Program.cs |
Operations/ and Configuration/ |
tests/NATS.Server.Tests/ |
Document in corresponding component |
golang/nats-server/server/ |
Reference material (not documented separately) |
Component Details
Protocol/
Documents the wire protocol and parser.
Source paths:
src/NATS.Server/Protocol/NatsParser.cs— state machine parsersrc/NATS.Server/Protocol/NatsProtocol.cs— constants, ServerInfo, ClientOptions
Typical files:
Overview.md— NATS protocol format, command types, wire formatParser.md— Parser implementation,TryParseflow, state machineCommands.md— Individual command formats (PUB, SUB, UNSUB, MSG, etc.)
Subscriptions/
Documents subject matching and the subscription trie.
Source paths:
src/NATS.Server/Subscriptions/SubList.cs— trie + cachesrc/NATS.Server/Subscriptions/SubjectMatch.cs— validation and wildcard matchingsrc/NATS.Server/Subscriptions/Subscription.cs— subscription modelsrc/NATS.Server/Subscriptions/SubListResult.cs— match result container
Typical files:
Overview.md— Subject namespace, wildcard rules, queue groupsSubList.md— Trie internals, cache invalidation, thread safetySubjectMatch.md— Validation rules, wildcard matching algorithm
Server/
Documents the server orchestrator and client connection handler.
Source paths:
src/NATS.Server/NatsServer.cs— accept loop, message routingsrc/NATS.Server/NatsClient.cs— per-connection read/write, subscription tracking
Typical files:
Overview.md— Server architecture, connection lifecycle, message flowClient.md— Client connection handling, command dispatch, write serializationMessageRouting.md— How messages flow from PUB to subscribers
Configuration/
Documents server configuration options.
Source paths:
src/NATS.Server/NatsOptions.cs— configuration modelsrc/NATS.Server.Host/Program.cs— CLI argument parsing, Serilog setup
Typical files:
Overview.md— All options with defaults and descriptionsLogging.md— Serilog configuration, log levels, LogContext usage
Operations/
Documents deployment and operational concerns.
Source paths:
src/NATS.Server.Host/— host application
Typical files:
Overview.md— Running the server, CLI argumentsDeployment.md— Deployment proceduresTroubleshooting.md— Common issues and debugging
GettingStarted/
Documents onboarding and project overview.
Typical files:
Setup.md— Prerequisites, building, runningArchitecture.md— System overview, Go reference mappingDevelopment.md— Development workflow, testing, contributing
Ambiguous Cases
| Code Type | Document In |
|---|---|
| Logging setup | Configuration/Logging.md |
| Integration tests | Operations/Testing.md or corresponding component |
Shared interfaces (IMessageRouter, ISubListAccess) |
Server/Overview.md |
| Go reference code | Don't document separately; reference in .NET component docs |
Adding New Components
When a new module is ported (Authentication, Clustering, JetStream, etc.):
- Create a new folder under
Documentation/ - Add at minimum
Overview.md - Add this mapping table entry
- Update CLAUDE.md documentation index if it has one
- Cross-reference from related component docs