Code Style Guide

The rules live in CONTRIBUTING.md; this page expands on why.

No linter/formatter is enforced yet, but the existing code leans on a few conventions worth matching:

Comments explain why, not what. Skip a comment if the code already says what it does. A comment that restates the next line in English is noise; one that explains a non-obvious constraint (an RFC requirement, a database gotcha, a trade-off that isn't visible from the code alone) is the kind worth writing.
Reuse an existing pattern over inventing a new one for the same kind of problem. e.g. optional features are gated by an unset config value (see Configuration Reference) rather than a separate feature-flag mechanism — every optional feature in this codebase follows that same shape.
Keep changes scoped to what's actually needed. This codebase avoids speculative abstraction for cases that don't exist yet — build the thing the current requirement needs, not a general system for requirements that might show up later.