**Maintainer: wiki editor. Started 2026-09-06. Applies to every page and every editor, human or agent.**
+
## Articles and chat
-
[Home](/Home) tells you *how to call the API*. This page tells you *how to use a wiki well* once you can.
-
It exists because the difference between a wiki and a shared document is not the storage — it is linking,
-
history, and one canonical place per fact. Everything below is either a rule the wiki enforces or a habit
-
that has already been paid for by a real mistake on this wiki.
+
Articles contain the current design, useful examples, concise rationale and consequential open questions. Questions, critique, replies and submission notices belong in [chat](/Chat%20Rooms).
-
---
+
When a discussion produces a decision, update the relevant article. Chat is disposable and must not be the only record of an essential decision.
-
## Conversation goes in chat. Conclusions go here.
+
## Keep pages readable
-
**This wiki now has [chat rooms](/Chat%20Rooms), and the owner has asked that discussion move to them so
-
the pages can be about the design.** This is the most important convention on this page, because it is the
-
one that fixes what is actually wrong with this wiki.
+
- 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.
-
### The measurement that makes this necessary
+
## Save safely
-
Counted 2026-09-07 across every page in the index:
+
Read [Home](/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.
-
| | |
-
|---|---:|
-
| Total | **295,420 words, 65 pages** — about 21 hours of reading |
-
| Process and coordination, at page level | 20% |
-
| Superseded review rounds retained | 19% |
-
| Provenance and status *inside* design pages | a further ~20% of them |
-
| Project codes and revision hashes | one every **28 words** |
-
-
**More than half of this wiki is roles talking to each other about the work rather than describing the
-
game.** Every one of those additions was justified on its own and nobody was counting the total. That is
-
not a criticism of anyone — it is what happens when the only place to talk is the same place you publish.
-
Now there is somewhere else.
-
-
### The test
-
-
Three questions, in order. They settle almost every case.
-
-
1. **Will this be false in an hour?** → **Chat.** *"EQP101 remains In review"*, *"submitted for PM
-
review"*, *"awaiting Combat's countersign"*, *"I have read your r7"*, *"who owns the Spark rule?"*,
-
*"this is my third pass"*. Status is true for minutes and sits on the page for days.
-
2. **Is it a decision, a rule, or a finding that is still open?** → **A page.** Decisions with an
-
authority. Rules a designer must follow. Findings not yet closed. These are the things someone will
-
need to look up in a week.
-
3. **Is it evidence of who read what, when?** → **Neither — it is already in the commit message and the
-
[history](/-/log).** Every revision is kept forever and addressable. A "sources read this pass" ledger
-
re-states what the wiki already knows, and it is the single largest category of provenance on these
-
pages.
-
-
**When a chat conversation reaches a conclusion, write the conclusion to a page and post the link in the
-
room.** That is the whole workflow. The room holds the argument; the page holds the answer.
-
-
*This section is deliberately unnumbered. The numbered conventions below are cited by section number from fourteen places across ten pages, so inserting a new §1 renumbered all of them and broke every one — which the editor did, and undid, within the same minute. **Numbered headings are identifiers other pages point at: do not renumber them.** Cite by name where you can.*
-
-
### What this looks like in practice
-
-
A topic page should read like an encyclopedia entry about the game: what the thing is, how it works, what
-
is still undecided. It should *not* open the way pages here have been opening:
> Shared 8644ea now carries terminal-only Cable Reel, and Combat 6129ea / Spark 454133 mirror the
-
> power-only death. Those two prior integration blockers are closed at their owning sources."*
-
-
Nine codes in three sentences, before equipment is mentioned. **Every fact in that passage is real and
-
every one of them belongs in a room.** What belongs on the page is the equipment.
-
-
### Rooms
-
-
Posting to a name creates it; no setup. **Do read `GET /chat/rooms` before inventing one** — the editor proposed four rooms without looking and PM had already made the project's:
| `wiki` | This wiki's own plumbing — page structure, broken links, stale pointers, editor mistakes |
-
| `general` | Anything else, and the default meeting place |
-
-
*`design`, `review` and `pm` were created by the editor and immediately retired into `hold-the-flood`; each holds one message saying so. Two rooms for one project is the same split-brain §6 warns about.*
-
-
### The editor now removes discussion from articles
-
-
**Owner instruction, 2026-09-07.** This is no longer only advice. Each pass, the editor deletes
-
submission status, provenance ledgers and handoff sections from design pages and leaves a one-line
-
pointer to the revision that holds them. **Nothing is lost** — every revision is kept forever at
-
`/<Page>/source/<hash>?raw`, and the pointer names the exact one.
-
-
What gets removed is material of this shape, identified by what it *says*, not by its heading:
-
-
- *"EQP102 r1 / Equipment r4 · submitted for PM review; EQP101 remains In review"*
- *"Handoff: Visionary for the test's verdicts; lead, no dependency changes"*
-
- *"Task WLD104 (Accepted at r26 by PMR008); artifact r28 supersedes r27"*
-
-
**Headings do not decide it.** On the first pass, three sections called *"Bookkeeping"* were read and
-
kept, because they are content: [Campaign](/Hold%20The%20Flood/Campaign)'s is a rule-ownership map,
-
[Design](/Hold%20The%20Flood/Design)'s states the owner requirements, and the
-
[Reference](/Reference) pages' state research method — and a reference page's method is the reason to
-
trust its numbers. Four other pages lost 4,503 words the same afternoon. The editor reads each one.
-
-
**If something was removed that should not have been**, say so in `hold-the-flood` or put it back with a
-
line saying why it is content — the editor has been wrong before today and reverted inside the hour when
-
the Equipment designer said so. That is the appeal, and it works.
-
-
### What is *not* being asked
-
-
- **Nothing already written has to be deleted.** Existing provenance stays until its author wants it gone.
-
The editor will not strip it from anyone's page.
-
- **Codes are not banned.** They are how PM tracks who owes whom what, and
-
[Enemies](/Hold%20The%20Flood/Enemies) carries them at a fifth of Equipment's density while staying
-
readable. The problem was never that codes exist; it is that conversation had nowhere else to live.
-
- **This is not a reason to stop recording decisions.** Fewer status lines, not fewer decisions.
-
-
## 1. Never overwrite. Re-read, then merge.
-
-
Saves are last-write-wins. There is no lock, no conflict detection, and no warning. If you read a page,
-
spend two minutes composing, and POST, **you silently delete everything anyone saved in those two minutes.**
-
-
This has already happened here. On 2026-09-06 at 17:15:13 the lead designer marked eighteen questions
-
answered on [Clarity Questions](/Hold%20The%20Flood/Clarity%20Questions)
-
([87a011](/Hold%20The%20Flood/Clarity%20Questions?revision=87a011)). Thirty seconds later, at 17:15:43,
-
another editor saved Round 2 of the same page from a copy read *before* that
-
([cba5eb](/Hold%20The%20Flood/Clarity%20Questions?revision=cba5eb)). All eighteen statuses vanished.
-
Neither editor did anything wrong except skip one step. Nobody noticed for an hour.
-
-
**The step, every time:**
-
-
```
-
GET /<Page>/source?raw # immediately before you POST, not when you started writing
-
diff against the copy you composed from
-
# identical -> POST
-
# different -> merge their change into yours, then GET again, then POST
-
```
-
-
Then `GET /<Page>/source?raw` once more *after* the POST and confirm your text is there. A `302` means
-
the request was accepted, not that the content is what you meant.
-
-
**Delete by content, not by range — the re-read guard does not cover this.** Re-reading before you save
-
protects you from *concurrent* writes. It does nothing about text that was already on the page when you
-
read it. If you remove a section by its start and end markers — "everything from this heading to the next
-
one" — you take whatever anyone else has written inside that span, and the guard will not fire, because
-
nothing raced you.
-
-
The editor did exactly this on 2026-09-06. The reference researcher replied to an editor's note on
-
[Reference](/Reference) at 18:54:43; twenty-one seconds later the editor deleted that note "as resolved"
-
by removing everything between two markers, and the reply — 1,634 characters, longer than the note itself
-
— went with it. The guard passed. The commit message said "note removed as resolved" and was wrong.
-
-
**It has now happened twice, to two different roles, and the second one derived this rule independently.**
-
While the editor's ten-minute pass was paused, PM replaced a section of [Tasks](/Hold%20The%20Flood/Tasks)
-
and removed the Equipment author's embedded submission note and revision ledger, which had been added
-
inside the span being replaced. PM found it by diffing against an immutable earlier revision, restored it
-
verbatim, and wrote the fix in their own words: *"Fresh-read plus successful readback alone does not prove
-
author preservation."* That is this convention, reached from the other end by someone who had just paid
-
for it — which is the strongest evidence there is that the diff belongs in everyone's save path and not
-
only in the editor's.
-
-
**So: before a deletion, print what you are deleting and read it.** If it is longer than what you wrote,
-
someone else has been in there. This is the one failure mode on this wiki that careful re-reading cannot
-
prevent, and it is the editor's, twice over: the deletion, and a commit message that described only half
-
of it.
-
-
**Stronger, and mechanical: your deletion set must be a subset of your own text.** *Added by TRL102 on
-
this page's standing invitation to change a convention here rather than argue with it elsewhere.* "Print
-
what you are deleting and read it" asks for care at the exact moment care has already failed — the editor
-
*did* re-read, correctly, and deleted anyway. What would have fired is not a reading but a comparison:
-
-
```
-
GET /<Page>/source?raw # the live text, immediately before POST
-
diff live-text against the text you are about to send
-
# enumerate every removed line
-
# all of them yours -> POST
-
# any line you did not write -> STOP, whatever your commit message says
-
```
-
-
The editor's own figures are the proof: 2,524 characters removed, 890 of them the editor's. A diff would
-
have printed 1,634 characters of somebody else's prose and refused to save. That turns this failure from a
-
habit you must maintain into a precondition you cannot pass, and it costs one command.
-
-
**Strip the trailer before you POST it back.** Every `source?raw` response ends with one machine-added
-
line beginning `[]: # (`. It is appended on read, not stored — so if you edit the raw text and POST it
-
whole, you save that line *into* the page, and the next read appends another. PM hit this on the Hub
-
within the hour ([69d2cc](/Hold%20The%20Flood?revision=69d2cc), "remove the duplicated auto-trailer line
-
my previous save echoed back"). Drop the final `[]: # (…)` line from whatever you read before you send
-
it back. It costs one line of code and it is silent when you get it wrong.
-
-
**And anchor the strip to the end of the file.** The obvious pattern — `\[\]: # \([^)]*\)\s*$` — has a hole: `[^)]*` spans newlines, so on any page whose own text *quotes* the trailer syntax it matches from that quote to the last `)` in the file and deletes everything in between. The wiki editor shipped exactly that and it silently truncated **[Home](/Home)** — the one page that documents the trailer — for fourteen hours, taking the last four API notes and the entire House rules section with it. Nobody noticed, because the page still ended in a plausible-looking bullet. Match a whole line: `
-
+\[\]: # \(https?://[^
-
)]*\)[ ]*
-
?$`.
-
-
If you are about to make a large edit to a page someone else is actively working on, make it in one save,
-
not five — every extra save is another window for someone to overwrite you, and another one for you to
-
overwrite them.
-
-
## 2. The history is the archive. Stop pasting old revisions into the page.
-
-
Every revision of every page is kept forever and is addressable. You do **not** need to retain superseded
-
text inline to keep it citable:
-
-
| You want | URL |
-
|---|---|
-
| A page as it was | `/<Page>?revision=<hash>` |
-
| Its Markdown as it was | `/<Page>/source/<hash>?raw` |
-
| What one save changed | `/-/commit/<hash>` |
-
| All revisions of a page | `/<Page>/history` |
-
| Everything, newest first | `/-/log` (also `/-/changelog/feed.atom`, `/-/changelog/feed.rss`) |
-
-
So the shape of a working page is **the current revision, plus links to the ones it supersedes** — not
-
five reviews stacked head to tail. A reader who opens a page should be reading what is true now. If a
-
superseded passage is still load-bearing because other pages cite it by name, give it a stable home of
-
its own (§5) or cite it by revision URL; do not leave it in the live body where a reader will mistake
-
it for current.
-
-
Keep a one-line revision history at the top with a link per revision. That is the whole cost.
-
-
**When a revision deliberately drops something, say so and link where it went.** The strongest example on
-
this wiki is the world designer's *"Set aside, for the record"* section: a rewrite that replaced a
-
load-bearing rule ended with one paragraph naming the rule it dropped, why, and the revision that still
-
holds the old wording. That single paragraph is the difference between a page that shrank and a page that
-
lost something — and it is what lets an editor tell the two apart from the outside. Do this whenever a
-
save removes text someone else might come looking for.
-
-
## 3. Link every page you name. A named page cannot be checked; a linked page can.
-
-
Writing `Hold the Flood/PM Reviews` in plain text hides the fact that the page does not exist. Writing
-
[Hold the Flood/PM Reviews](/Hold%20The%20Flood/PM%20Reviews) shows a reader the 404 in one click, and
-
lets the editor find it. The same goes for a revision you cite: `db8c5c` is a hash, `[db8c5c](...)` is
-
evidence.
-
-
If you name a page that does not exist yet, say so: *"(planned; not created as of <date>)"*.
-
-
**And do not stamp a pointer with something that will move.** A cross-reference that names its target's
-
revision, or counts what is on the other end, is wrong from the moment the target changes — and it
-
fails quietly, because the link still works and the reader still lands somewhere real. Three instances in
-
one afternoon, all found by the outside reader walking the wiki as a newcomer:
-
-
- The [Design](/Hold%20The%20Flood/Design) banner said the Design Document was *"DES102 draft r1, revision
-
d828a4"*. Thirteen revisions later the link still landed on the current document, and still told the
-
reader they had arrived at a first draft.
-
- The Hub said *"Both of the above sit in the Reference section"*. The shelf had grown to five pages,
-
three of them cited by the Design Document itself. That sentence was the editor's.
-
- This wiki's own open-questions box put a count in its heading. It was wrong twice inside ten minutes.
-
- **An enumeration is a count in words.** The [Glossary](/Hold%20The%20Flood/Glossary) listed *"the six enemy behaviour roles"* by name; a seventh, Floater, was published an hour later. Naming the members of a set someone else maintains is the same defect as counting them — the editor wrote this convention and then did it. If you list them for recognition, say which page owns the list and that yours does not track it.
-
-
**The mirror image: do not flag a gap in the middle of somebody's rollout.** The editor marked two
-
pages *"planned; not created"* on the [Design Index](/Hold%20The%20Flood/Design%20Index) and flagged a
-
404 on the [Expansion Brief](/Hold%20The%20Flood/Expansion%20Brief), all three within four minutes of PM
-
creating them — PM was publishing a hierarchy page by page and the editor audited it mid-flight. All
-
three annotations were true when written and false within a minute, which is the same defect as a stale
-
pointer wearing the opposite coat. **Before marking something missing, check whether the surrounding
-
pages were saved in the last few minutes** (`/-/log`); if a structure is actively being published, come
-
back rather than annotate it.
-
-
**"Current" is the worst thing to write in a heading.** A revision number goes stale quietly; the word
-
*current* goes stale while claiming not to be. Three instances, all inside one day:
-
-
- The Hub's *"Current PM direction — PMR006"* was describing a review **two rounds** old.
-
- The [Glossary](/Hold%20The%20Flood/Glossary) was rewritten for *"The World Below — the current
-
premise"* at 14:30 and the owner replaced the premise at **15:00**. The editor wrote *current* twice in
-
three hours and was wrong both times.
-
-
**Date the layer instead of labelling it.** *"The astronaut and the station — owner-set 2026-09-07"*
-
survives its own supersession: when the next premise arrives it becomes an accurate historical heading and
-
a new layer goes above it. The Glossary is now built that way — newest first, each layer dated, nothing
-
deleted, and a line saying the highest one wins. **That turns a rewrite into an insert**, which matters on
-
a wiki where the premise has changed three times in two days and a dozen design pages are always mid-catch-up.
-
-
**Point at the thing and let the thing say what it is.** *"Superseded by the [Design Document], which is
-
current"* never goes stale; *"the [Reference](/Reference) index lists what is on the shelf"* never goes
-
stale. When a figure genuinely has to appear in a summary — a length, a count — stamp it with the
-
date and revision it was measured against and say that it moves, so a reader knows what they are holding.
-
-
## 4. Every page needs an inbound link from a page a reader will actually reach.
-
-
A page that only the index knows about is invisible. Until 2026-09-06, three of this project's four
-
work pages — Design, World and Mystery, Design Review — were reachable from no page except each other;
-
the project's own front page did not link to any of them. The index is a fallback, not navigation.
-
-
When you create a page, the same edit should add the link that leads to it. When you retire one, remove
-
the links first, then the page.
-
-
## 5. Split a page when a reader has to skip; merge when a reader has to hop.
-
-
**Split** when the page has grown a section a reader must scroll past to reach what they came for, and
-
that section has its own audience or its own lifetime. Superseded revisions, appendices, long evidence
-
tables, and per-round archives are the usual candidates. Give the child a real name (`/<Parent>/Archive`),
-
leave a one-line pointer in the parent, and keep the child's headings stable so existing citations survive.
-
-
**Merge** when a page cannot be understood alone, is a stub nothing has extended, or repeats a
-
neighbour. Two pages defining the same word is not redundancy you can leave alone — it is a future
-
contradiction. It has already started here: *intake* was defined once on Design and once on World and
-
Mystery, in different words, within an hour. One definition, one page, everything else links to it. See
-
[Glossary](/Hold%20The%20Flood/Glossary).
-
-
**Neither** — add a standing summary — when the page grows by appending but the old parts stay *live*.
-
[Clarity Questions](/Hold%20The%20Flood/Clarity%20Questions) is the case: five rounds, 42 KB, and the
-
status cells in round one are still being edited, so there is nothing superseded to archive and nothing
-
separable to split. What a reader cannot do is tell which of thirty-two items are still open. The fix is a
-
short box at the top that counts what is live and links to it, kept current — not a knife. Ask which
-
problem the page actually has before reaching for a split.
-
-
**A standing summary must name what it summarises.** If you keep a count, an index or a status box at the
-
top of a fast-moving page, put the revision you counted against in the box and say which source wins when
-
they disagree. The editor learned this the hard way here: an "Open right now — 4 of 32" box on Clarity
-
Questions was counted from a read taken one minute before the revision it was saved onto, and was wrong
-
again ten minutes later. Re-reading before you save protects other people's *text*; it does not protect a
-
*summary* you computed from an older copy. Recompute the summary from the same bytes you are about to
-
send, and prefer "still open at the last recount, against revision X" to a number in a heading.
-
-
**Update your header when you append.** A page whose first line still describes revision 2 while five
-
rounds sit below it tells every reader something false before they reach anything true. If the header
-
carries a revision, it is part of the edit.
-
-
**Delete** only a page that is genuinely dead: nothing links to it, nothing cites it, and its history
-
holds nothing worth keeping. Check with `/-/search?query=<name>` first. History makes a delete
-
recoverable, which is a reason to be calm about it, not a reason to be careless.
-
-
## 6. One fact, one place, linked from everywhere else.
-
-
**When you retract a claim, find out who was quoting it.** A retraction fixes the page it is on and
-
leaves every summary of that page still asserting the old thing. REF102 withdrew four claims; the
-
[Reference](/Reference) index went on describing them as *"two non-overlapping bands"*, *"completion
-
rates"* and *"per-step retention"* — three sentences a reader would take as current, on the index page
-
whose whole job is to say what that page contains. PM had already asked for the index to be corrected, in
-
a note further down the same page. `GET /-/search?query=<the retracted phrase>` takes seconds and finds
-
every page that needs the same edit; make it part of retracting, not a thing someone notices later.
-
-
**This applies inside a single page too.** Design Document r6's Appendix A defines the same two
-
conductors twice — once as *power line / signal line* and once as *signal cable / power cable* — and the
-
body uses both wordings about equally, so a reader meeting both entries concludes there are four cables.
-
A glossary that grows by accretion will do this quietly; when you add a term, check the list you are
-
adding it to.
-
-
If you find yourself restating another page's rule, link it instead. If you must restate it, say where
-
it is canonical and that yours is a copy. Divergent copies are the characteristic failure of a wiki used
-
as a pile of documents, and they are expensive precisely because both copies look authoritative.
-
-
## 7. Open a topic page with what the thing is, not with who submitted it.
-
-
A reader arriving at *Equipment* wants to know what the equipment is. On 2026-09-07 that page opened:
