Two-Tier Documentation

Reference documents live in the repository and are versioned with the code; narrative and community content lives in the GitHub wiki.

DPC splits documentation by volatility, not by audience. Anything that must match the code exactly lives in the repository; anything that changes on its own schedule lives in the wiki.

What goes where

In the repository (required): README.md, CONTRIBUTING.md, USER_GUIDE.md, COMMANDS.md, CONFIG.md. Recommended: CHANGELOG.md. When applicable: a flags reference such as FACTION_FLAGS.md, and DATABASE_QUERYING.md.

In the wiki: Guide, FAQ, Placeholders, Developer Notes, External API documentation.

The reason for the line

COMMANDS.md and CONFIG.md are the test case. A command's syntax and a config key's default are facts about a specific version of the code. Put them in a wiki and they describe whatever the latest release happens to be — which is wrong for everyone running anything else, and impossible to fix in a pull request.

In the repository, they are versioned: they change in the same commit as the code, review together, and a user reading the docs for the tag they installed gets the truth.

The wiki gets what benefits from not being versioned — a narrative guide, an FAQ that grows as questions arrive, community-maintained pages that would otherwise need a maintainer's review for a typo.

The line is not perfectly held

The convention places FAQ in the wiki, but Medieval Factions now also carries an in-repo FAQ.md linked from its README. Whether that is the convention drifting or the flagship leading it is not recorded anywhere; note only that the two currently disagree.

Applied here

This zettelkasten sits on the same side of the line as COMMANDS.md: its claims are about specific commits, so they are pinned to SHAs rather than left to track main. See the note format.

Related

The rule is enforced by review rather than tooling — DPC Conventions describes the shape, and an audit is a matter of checking which files exist.