Skip to content

Standards

Purpose. Define how code, documentation, tests and commits must look, so that quality is a property of the process rather than of who happened to write it.

Responsibilities. - Set enforceable limits on size, complexity and coupling. - Define the documentation contract. - Define what must be tested and how. - Define the git workflow.

Not responsible for. Design decisions — those are in Architecture/ and ADR/. These documents say how to express a decision, not which decision to make.

Dependencies. None. Read these before writing any code.

Public API. N/A.

Future improvements. The rules marked "enforced by review" should migrate to analyzers where possible — .editorconfig and Roslyn analyzers land with the Core milestone.


Contents

Doc Covers
00_CODING_STANDARDS.md Size limits, type design, async, S&box specifics, server authority, the forbidden list
01_NAMING.md Casing, banned abbreviations and suffixes, the domain vocabulary
02_DOCUMENTATION_STANDARDS.md The four documentation layers, XML docs, file headers, comment rules
03_TESTING_STANDARDS.md Engine-agnostic rules, MSTest harness, required coverage, the exploit checklist
04_GIT_WORKFLOW.md Branches, commit format, merge policy, tags and releases
05_ISSUE_TRACKING.md GitHub Issues, area labels, milestones, linking commits to issues
06_ART_PIPELINE.md Blender source-file location, naming/scale/collision conventions, export and compile-to-.vmdl steps

The three rules that shape everything else

If you remember nothing else from this folder:

  1. Game rules live in engine-agnostic types. If it cannot be tested without launching the game, it is in the wrong place. (03)

  2. Every piece of state has exactly one owning module. No shared mutable bags, no static mutable state. (00)

  3. Documentation lands in the same commit as the code. Not the next one. (02)