Die Seiten von Denotato — was auf jeder steht und was man dort tun kann

Hinweis: Diese Ablage ist die Quelle, der Code ist die Gegenprobe.
Christian am 16.09.2026: „Bitte schreibe zu jeder Page noch eine jeweilige Doku-Datei die alle Buttons, Aktionen und Anzeigen dieser beschreibt und gepflegt wird damit du nicht immer aus dem Code interpretieren musst sondern dieser nur zum Nachprüfen ist."
Bis hierher stand, was ein Schirm kann, ausschließlich im Schirm. Wer wissen wollte, welche Knöpfe /tasks hat, las 344 Zeilen TSX und hoffte, nichts übersehen zu haben. Das ist nicht nur langsam — es ist unsicher: ein Knopf, den man beim Lesen überspringt, existiert in der nächsten Planung nicht mehr.

Die Regel

Wer einen Schirm anfasst, zieht seine Datei nach — spätestens im Doku-Commit am Ende des Auftrags, vor dem Push (im eigenständigen Modus: am Ende der Welle). Sie darf auch schon im Code-Commit liegen. Ein neuer Knopf ohne Zeile hier ist wie ein Endpunkt ohne MCP-Werkzeug (Grundsatz 47): der Bestand beschreibt dann ein Denotato, das es nicht mehr gibt, und man merkt es erst am Fehlschlag.

(Bis zum 23.09.2026 hieß es „im selben Commit"; N146 hat die Doku ans Ende des Auftrags gelegt. Code und Seitendatei liegen weiter im selben Push.)

npm run verify:seiten --prefix packages/backend hält fest, dass es zu jedem Bereich im Register eine Datei gibt und dass keine Datei einen Bereich beschreibt, den es nicht mehr gibt.

Was in einer Datei steht

Jede Datei hat dieselben sechs Abschnitte, in dieser Reihenfolge:

Der letzte Abschnitt ist der, der die Ablage lebendig hält. Er ist kein Mängelbericht, sondern die Liste dessen, was beim nächsten Mal drankommt.

„Was fehlt" ist die unsicherste Stelle — und wird geprüft

Die ersten fünf Abschnitte jeder Datei stehen im Code und lassen sich dort nachschlagen. Der sechste ist eine Behauptung über eine Abwesenheit, und die ist schwerer zu belegen als eine Anwesenheit: man kann nicht sehen, was nicht da ist, man kann nur nirgends darüber stolpern.

Beim ersten Durchgang am 16.09.2026 standen deshalb sechs Punkte darin, die es längst gibt — die Stufe als Kristall, die drei Metalle, „Skill anlegen", die Farben an Auswahlwerten, das Zurücknehmen einer Karte und die Dateiablage. Alle sechs waren aus der Bauteilliste erschlossen und nicht am Code geprüft.

Beim zweiten Durchgang in der Nacht zum 17.09. kamen sechs weitere dazu: vier auf /memories (Suche, Datum, Herkunft, Bearbeiten), dazu der LaTeX-Export des Arbeitsblatts auf /tutor und die Personen an einem Ereignis auf /life — Letztere mit 52 Verknüpfungen in der Datenbank.

Der Grund ist derselbe und lehrreich: alle liegen auf Schirmen, die keine Tabelle zeigen. Die Auswertung, aus der ich die Dateien geschrieben habe, sucht nach Spalten, Knöpfen und Beschriftungen — und fand dort fast nichts. Wo sie nichts fand, habe ich „gibt es nicht" geschrieben statt „habe ich nicht gesehen".

Elf falsche Punkte von 214. Das ist die Fehlerquote einer Methode, nicht eine Reihe von Ausrutschern: eine Abwesenheit, die aus dem Ausbleiben eines Treffers erschlossen ist, ist geraten.

Sie stehen jetzt durchgestrichen mit der Korrektur daneben und werden nicht stillschweigend entfernt: wer einmal gelesen hat, dass etwas fehlt, soll auch lesen, dass es das nicht tut.

Die Regel daraus: ein neuer Punkt unter „Was fehlt" nennt, wo er gesucht hat — ein Endpunkt in endpointPaths.ts, eine Datei, ein Bauteil. Wer nur „gibt es nicht" schreibt, hat nicht nachgesehen.

Und weil eine Regel, die niemand prüft, keine ist: verify:seiten prüft jeden Endpunktnamen, den eine Datei in Backticks nennt, gegen endpointPaths.ts. Beim ersten Lauf fiel sofort einer heraus: in materials.md stand ein erfundener Name für die Quellen — sie heißen SOURCES, SOURCE_SAVE, SOURCE_SEARCH und SOURCE_TEXT.

(Der falsche Name steht hier absichtlich nicht ausgeschrieben: die Prüfung liest jede Datei in diesem Verzeichnis, auch diese, und ein Gegenbeispiel in Backticks wäre ein Fehler, der sich selbst erzeugt. Das ist der erste Lauf gewesen, an dem das aufgefallen ist — durch genau diesen Fehler.) Die Prüfung fängt auch den häufigeren Fall: ein Endpunkt wird umbenannt, und die Beschreibung sagt weiter den alten Namen.

Die Nummern unter „Was fehlt" sind Fundstellen

Ein Vorgang verweist auf einen Punkt, indem er ihn zählt — quelle: seiten/randseiten.md 8. Damit ist die Nummer keine Aufzählung mehr, sondern eine Adresse. Sie hält nur, wenn zwei Dinge gelten:

• Die Nummern laufen durch, von 1 bis zur letzten, in der Reihenfolge, in der die Punkte stehen. In randseiten.md zählten sie 1, 2, 11, 12, 3 … 10, weil zwei Punkte nachträglich oben eingefügt und hinten weitergezählt wurden. S-randseiten 8 traf damit den Punkt, den man an achter Stelle liest, und nicht den, der 8 heißt — zwei verschiedene Sätze, und nichts sagte einem, welchen man vor sich hat. Am 21.09.2026 einmal durchnummeriert (K02).
• Ein neuer Punkt kommt unten dazu, nie in die Mitte. Wer oben einfügt, verschiebt jede Nummer darunter, und jeder Verweis darauf zeigt danach auf den Nachbarn. Ein widerlegter Punkt wird durchgestrichen und bleibt stehen (siehe oben); seine Nummer wird deshalb auch nicht neu vergeben.

Beides prüft kein Nachweis: verify:seiten zählt die Punkte, er liest sie nicht. Wer umnummeriert, zieht die Verweise von Hand nach — sie stehen im quelle:-Feld der Vorgänge und sind mit grep zu finden.

Die Dateien

Und die Ideen

Was auf einer Seite fehlt, steht in ihrer Datei unter „Was fehlt". Was daraus ein Vorhaben geworden ist, steht gesammelt und bewertet in [../kontext/ideen.md](../kontext/ideen.md).