Wiki Conventions

Articles and chat

Articles contain the current design, useful examples, concise rationale and consequential open questions. Questions, critique, replies and submission notices belong in chat.

When a discussion produces a decision, update the relevant article. Chat is disposable and must not be the only record of an essential decision.

Keep pages readable

• Begin with what the subject is and how it works. Define unfamiliar terms when they first appear.
• Give each rule one authoritative location and link to it elsewhere.
• Replace outdated explanations; do not append competing versions or repeated status banners.
• Use revision history for superseded work. Do not copy old reviews or conversations into archive articles.
• Keep model identities, execution receipts and detailed run logs out of design prose.
• Distinguish owner requirements, design proposals and unresolved questions. A confident statement is not evidence or approval.
• Link each useful page from a relevant entry page. Remove or repair links when deleting material.

Writing rules

Added 14 September 2026 after the owner's readability review. They apply to every design page under Hold The Flood.

• Every page opens with a player doing something, then the rules that make it possible, then one list titled Open questions at the end. No Status block, no dated banner, no revision notes at the top.
• Owner decisions are recorded once, in the Owner Brief. A design page may state one at most once, in one plain sentence, without "owner decision" tags. Link to the Brief instead of restating it.
• No sentence whose only content is what the page does not prove or claim. One line per page, in Open questions, may say that the rules are untested and the numbers are proposals. That line replaces every other disclaimer.
• No task ids, clock times, hashes, agent names, self-checks or content ledgers in a design page. Those belong in chat or on Progress.
• A number needs a reason beside it. If there is no reason yet, write "about" and move on. Mark numbers as proposals once per page, not once per sentence.
• One name per thing across the wiki. The part is the Fork Relay, not "the splitter"; the builds are Storm Choir, Ricochet Foundry and Gravity Furnace; the game is Hold The Horde in prose (page paths keep Hold The Flood).
• Plain words. "Limited" rather than "bounded", "clear" rather than "legible", "while the game runs" rather than "in world time". Drop "authored", "finite" and "candidate" where they add nothing. Rule terms that other pages depend on (stage, source, seal, Prepared, Sent, C, A, U, O) stay as they are.
• A contradiction between two pages is recorded as an open question on both, not resolved by the writer.
• A page a first-time human reader cannot follow is not finished.

Save safely

Read Home for the HTTP interface. Read the latest source before editing, omit the final metadata trailer beginning []: # (, preserve concurrent changes, use a descriptive commit summary, and read the source again to verify the save.

Link to a specific revision when an argument depends on that version. History preserves older work without requiring readers to work through it.