Numbers are identity; the reading order is a generated, checked index

Decided after measuring what renumbering actually costs: 96 references in code
comments across two repositories, none of which would have failed to compile.
They would have pointed at the wrong reasoning, which is worse than a broken
link because nothing reports it.

So a number identifies a record and never changes. It cannot also be a
position -- a position moves when the set changes, and an identity that moves
is not one.

The reading order moves into an index generated from each record's `topic:`.
Six topics, in the order somebody learns the system.

The index is WRITTEN rather than only generated on demand, which reverses what
this repository previously said. The reason it said otherwise is that a
hand-written index drifts -- but a reader looking at the folder on a forge sees
the folder, not a command, and the drift objection is answered by checking
rather than by refusing to write one. That is §5's own rule: a rule states how
it is checked.

Two checks, both confirmed to bite. index.py fails when the written order no
longer matches the records. records.py fails when a record has no topic or one
nobody defined -- the quiet failure being a record that vanishes from the order
rather than appearing in the wrong place.

02-DECISIONS/0019-how-this-repository-works.md

@@ -1,4 +1,5 @@
 ---
+topic: how we work
 status: accepted
 date: 2026-08-28
 deciders: jochen
@@ -77,11 +78,25 @@ settled. Everything else belongs in the design document, where the reasoning is
 **There is no ledger** — no separate document summarising, ranking or tracking decisions. A
 chronological view is generated from frontmatter, which is what a ledger was actually for.
 
-**The numbering is the flow here too.** Records are ordered the way somebody would learn the
-system — what the mesh is, then its tiers from the bottom up, then what runs on them and how it
-gets there, then how it is built, how it is checked, and how we work. **Not chronologically**: the
-date is in the frontmatter and a consolidated record holds decisions taken across a week, so
-ordering by age would order by an accident that no longer exists.
+**A number identifies a record and never changes.** It is not a position, and it cannot be
+both — a position moves when the set changes, and an identity that moves is not one.
+
+That is not a preference. Records are referenced from **outside** this repository: code
+comments, commit messages, the knowledge base. Renumbering once cost 96 references across two
+code repositories, and nothing in either would have failed to compile — the comments would
+simply have pointed at the wrong reasoning, which is worse than a broken link because nothing
+reports it.
+
+**So the reading order lives in a generated index**, from each record's `topic:` — what the mesh
+is, then its tiers from the bottom up, then what runs on them and how it gets there, then how it
+is built, how it is checked, and how we work.
+
+**And the index is written, not only generated on demand.** A reader looking at the folder on a
+forge sees the folder, not a command. The objection to a written index is that it drifts, and
+that is answered by **checking** it rather than by refusing to write one — which is §5's own
+rule: a rule states how it is checked. A record with no topic, or a topic nobody defined, fails
+the same check, because the quiet failure is a record that vanishes from the order rather than
+appearing in the wrong place.
 
 **The design layer is what you read.** These records explain *why* a thing is as it is. They are
 not a description of the system, and needing to read them to understand it would mean the design