/admin — Der Reiter „Admin“: Vorgänge und Verwaltung

Hinweis: Rahmen: 00-rahmen.md. Code: packages/plugins/src/admin/ — client/Verwaltungsmenue.tsx, client/Kachel.tsx, client/Projektkachel.tsx, client/Vorgangskarte.tsx, client/Schrittliste.tsx, client/Vorhabenbaum.tsx, client/Tafel.tsx, client/Vorgangssuche.ts, client/Fortschrittsbalken.tsx, client/Systemtafel.tsx, client/Einfallsfach.tsx, client/Entwurfsfach.tsx, client/rollen.ts, client/Bereichswand.tsx, client/Prioritaetswahl.tsx, client/Themenansicht.tsx, client/Kennzeichen.tsx, client/arten.ts, client/bereichsbild.ts, client/Loeschknopf.tsx, client/Loeschfach.tsx, client/Planbahn.tsx (seit N289 nicht mehr eingebunden), client/Erklaerung.tsx, client/Verwaltungsabschnitte.tsx, client/kontenAnfragen.ts, client/Gruppenpflege.tsx, client/gruppenAnfragen.ts (Gruppen, A05), client/Instanzwertpflege.tsx (Instanzwerte, N508), client/Oberflaechenpflege.tsx (Oberfläche, OE04), client/Gestaltungspflege.tsx (Gestaltung, E-261016-admin-schalter), client/Nutzungsauswertung.tsx (Nutzung, A45), client/Ideenablage.tsx (Ideen, KN-261015-ideenablage) · Leitstand (B-261013-leitstand-ansicht) unter client/leitstand/: leitstandRequests.ts, leitstandContext.ts, leitstandProps.ts, leitstandWords.ts, leitstandFormat.ts, leitstandFigureMath.ts, LeitstandView.tsx, LeitstandAccountBar.tsx, LeitstandDesk.tsx, LeitstandSessions.tsx, LeitstandAttention.tsx, LeitstandLanes.tsx, LeitstandLaneQuestions.tsx, LeitstandQuestions.tsx, LeitstandOverrides.tsx, LeitstandSettings.tsx, LeitstandLog.tsx, LeitstandNewMenu.tsx, LeitstandFigures.tsx, LeitstandWeekCurve.tsx, LeitstandUsageBars.tsx; Server server/leitstand.ts, server/leitstandState.ts, server/leitstandCommands.ts, server/leitstandLanes.ts, server/leitstandFigures.ts, server/leitstandTicks.ts · Erfassung im Gerüst: packages/frontend/src/components/nutzung/Nutzungserfassung.tsx, packages/frontend/src/handlers/nutzungsprotokoll.ts, packages/frontend/src/handlers/requests/nutzungHandler.ts, Routen packages/backend/src/routes/api/nutzung.ts · Schirm „Modell“ im Begleiter: packages/plugins/src/begleiter/client/Modellschirm.tsx, Stufentabelle.tsx, Protokolltafel.tsx, Monatsring.tsx, Instanzwerte.tsx, Modellwahltafel.tsx, Denkraumtafel.tsx, Fristtafel.tsx, Protokollfristtafel.tsx, Verlaufsfristtafel.tsx, Anstossschwellentafel.tsx, modellAnfragen.ts, Routen begleiter/server/verwaltungsrouten.ts · Schirm „LaTeX-Fehler“ im Bereich LaTeX: packages/plugins/src/latex/client/Fehlerpflege.tsx, Routen latex/server/fehlererklaerungen.ts · Schirm „LaTeX-Grenzen“: packages/plugins/src/latex/client/Satzgrenzenpflege.tsx, Routen latex/server/satzgrenzen.ts · Leser server/vorhabenlesen.ts, server/verwaltung.ts, server/bereichswand.ts, server/kurzzweige.ts · Filterleiste im Gerüst: packages/frontend/src/components/dataview/Filterleiste.tsx · Nachweis npm run verify:verwaltung, für Instanzwerte npm run verify:instanzwerte.

Wofür

Ein direkter Weg mit einer Vorgangskennung im Anker, etwa /admin#WI20, öffnet nach dem Laden die Karte dieses Vorgangs über der gewählten Sicht.

Der Stand der Arbeit an Denotato — in Denotato. Christians Auftrag vom 20.09.2026: „Ich brauche eine bessere Übersicht über deine Arbeit. Was in Arbeit ist, was fertig ist, wo Entscheidungen offen sind … und was noch für Ideen da sind die aber nicht von mir approved wurden."

Bis hierher stand das in docs/vorhaben/ — zweihundertachtundzwanzig Dateien, lesbar, aber nur mit einem Texteditor und nur von jemandem, der weiß, wonach er sucht. Und beantwortbar war es gar nicht: Eine Entscheidung ließ sich nur im Gespräch treffen, und was im Gespräch stand, war nach der nächsten Verdichtung weg.

Diese Seite ist keine zweite Vorgangsablage. Die Vorgänge bleiben Dateien im Repository (N80): Sie stehen in jedem Klon, wandern mit jedem Zweig, und ein Nachweis liest sie. Hier ist das Fenster darauf. Was hinzukommt, ist die Gegenrichtung — Christians Urteil, seine Kommentare und die Werte, die er stellt —, und nur die liegen in der Datenbank.

Damit ist der eigentliche Zweck erfüllt: ein Steuerkanal, der nicht das Chatfenster ist. Was er nachts hier sagt, hole ich beim nächsten Lauf über verwaltung_offen ab und trage es in die Dateien nach.

Weg und Rahmen

Was man sieht

Eine Spalte, zwei Teile (24.09.2026, A41, N253)

Links steht die Kategoriespalte, dieselbe wie in den Einstellungen (Kategoriespalte.tsx): zuerst Vorhaben und System, darunter die Verwaltung — Neue Konten · Vorgaben setzen · Für alle · Impressum · Instanzname · Blocknamen · Hochschulen · Fächer · Rollen · Gruppen · Konten · Instanzwerte · Oberfläche · Gestaltung · Nutzung · Ideen, dahinter Modell, LaTeX-Fehler und LaTeX-Grenzen, wenn ihr Bereich da ist. Alle außer Impressum (D47, 29.09.2026) Hochschulen (VA14, 30.09.2026), Fächer (VA13, 07.10.2026), Instanzwerte (N508, 04.10.2026) und Nutzung (A45, 05.10.2026) waren bis A41 die Kategorie Verwaltung der Einstellungen; Christian wollte, dass die Einstellungen nur zeigen, was ein Konto für sich selbst stellt (N224, N227). Jeder Abschnitt zeigt rechts Titel, einen Satz und seinen Inhalt; was dort steht, beschreibt settings.md, „Die Verwaltung: Rollen statt Gruppen“ — seit E22 (27.09.2026) auch das Material je Rolle unter Rollen und die Vergabe der Ränge unter Konten. Die Reiter der Darstellung (Bereiche · Kacheln …) und „Neu“ stehen nur unter Vorhaben. Auf dem Telefon wird die Spalte eine Zeile zum Wischen.

Ohne feature.admin wird der Stand nicht gelesen — die Antwort wäre eine 404, und ihr Fehler stünde über Abschnitten, die mit ihm nichts zu tun haben. Modell (KI02) ist die letzte Kategorie. Ihr Inhalt gehört dem Begleiter und kommt über dessen Klientanschluss in die Verwaltung; ist der Begleiter abgeschaltet, fehlt die Kategorie vollständig.

Abschnitte statt Karten (10.10.2026, ES-261010-restliche-kartenraster, Guide §15.1): Rechts steht jeder Abschnitt schon in seiner Fläche; seine Gruppen — unter Neue Konten, Instanzwerte und Modell — trugen darin bis dahin noch einmal Karton mit Rand, also Karte in Karte. Jetzt beginnt jede Gruppe unter einer Haarlinie, ohne eigenen Kasten (Verwaltungsabschnitte.tsx, Instanzwertpflege.tsx, Modellschirm.tsx im Begleiter). Kacheln bleiben, wo ein Eintrag Zustand und Bedienung trägt: die Hochschulen (Stand, Moodle fragen, Bearbeiten) und die Vorgangskacheln.

Neue Konten — Welcher Bereich welchem folgt (10.10.2026, LX24)

Zwischen „Was ein neues Konto bekommt“ und „Bitten nach Erfolgen“ steht die Karte Welcher Bereich welchem folgt (Kopplungskarte in Verwaltungsabschnitte.tsx). Ein Satz sagt, was eine Kopplung bewirkt: Wer den ersten Bereich ein- oder ausschaltet, schaltet den zweiten mit, ein neues Konto startet ebenso, einzeln umlegen bleibt möglich. Darunter je Paar eine Zeile, deren Satz die Vorschau ist — „Wer Studium einschaltet, bekommt LaTeX mit“ — und ein Kästchen. Ab Werk gibt es ein Paar (Studium › LaTeX, N446); es bleibt auch abgehakt stehen, damit der Weg zurück nicht verschwindet.

Das Kästchen schreibt die Instanzvorgabe plugins.folgen (Schicht instanz, nur sie): ein Objekt „führender Bereich → Folger“, {} heißt „keine Kopplung“. Geprüft wird beim Speichern (istFolgeregel): nur umschaltbare Bereiche, keiner folgt sich selbst, keiner doppelt. Neue Paare legt die Karte nicht an; die Einstellung nimmt jedes gültige Paar über das MCP oder „Für alle“. Gelesen wird sie beim Umschalten (bereichsschalter.ts), beim Anlegen eines Kontos (provisioning.ts), beim Aufnehmen eines Bereichs im Meta-Server und in db:seed-capabilities; fehlt sie oder taugt sie nicht, gilt FOLGT_DEM_BEREICH.

Die Vorgabe ab Werk an oder aus je Bereich stand schon vorher hier, in der Spalte „an“ von „Was ein neues Konto bekommt“ (plugins.vorgabeAktiv, N70).

Neue Konten — Zuschnitte beim ersten Start (14.10.2026, KN-261014-erststart-pflege)

Zwischen „Welcher Bereich welchem folgt“ und „Bitten nach Erfolgen“ steht die Karte Zuschnitte beim ersten Start (Zuschnittkarte in Verwaltungsabschnitte.tsx). Sie pflegt erststart.zuschnitte, die Zuschnitte, die die Erststart-Karte auf der Übersicht anbietet (dashboard.md); ohne gesetzten Wert stehen die Vorgaben aus VORGABE_ZUSCHNITTE da. Ein Satz sagt, wie gewählt wird: der kleinste Zuschnitt, der jeden Zweck des Kontos deckt, ohne Antwort der Schnellstart; Tagebuch und Gedächtnis schaltet jeder selbst ein.

Oben je Zuschnitt eine Zeile: sein Name als Feld (gespeichert beim Verlassen; ein geleerter springt zurück) und Entfernen — beim Schnellstart steht stattdessen „Schnellstart“, er lässt sich nicht entfernen. Darunter Zuschnitt hinzufügen (höchstens zwölf; der neue heißt „Neuer Zuschnitt“, Kennung zuschnitt-<n>, und steht vor dem Schnellstart). Darunter ein Gitter mit einer Spalte je Zuschnitt, die Namen im Kopf: unter Bereiche die elf Bereiche, die ein Zuschnitt umlegen darf (ZUSCHNITTSBEREICHE), unter Deckt die Zwecke die fünf Antworten auf „Wofür“. Jedes Kästchen schreibt die ganze Liste als Instanzvorgabe, und nur, wenn sie istZuschnittliste besteht. Am Telefon rollt das Gitter seitlich in sich, nicht die Seite.

Neue Konten — Bitten nach Erfolgen (10.10.2026, D-261008-erfolgsmomente)

Unter Neue Konten steht unter dem Abschnitt „Was ein neues Konto bekommt“ ein zweiter: Bitten nach Erfolgen (Bittengrenzenkarte in Verwaltungsabschnitte.tsx). Ein Satz sagt, wann gefragt wird: ein Gast nach seiner ersten gelernten Runde, ob er ein Konto anlegen will, nie mitten in einer Handlung. Darunter zwei Auswahlen:

Jede Wahl schreibt beide Zahlen zusammen als Instanzvorgabe bitten.grenzen (Schicht instanz, nur sie). Mehr als drei Bitten je Sitzung und weniger als ein Tag Ruhe nimmt die Probe nicht an: Das eine wäre Drängen, das andere ließe eine abgelehnte Bitte nach dem Neuladen gleich wiederkommen. Zurückgenommen wird ein gesetzter Wert unter Für alle. Was die Bitte zeigt und wann: 00-rahmen.md, „Die Bitte nach einem Erfolg“. Nachweis: Verwaltungsabschnitte.bitten.test.tsx.

Impressum — die Anschrift (D47, N407, 29.09.2026)

Die Anschrift im Impressum ist eine Einstellung in Denotato und steht nicht im Archiv (N407; warum, sagt randseiten.md). Der Abschnitt zeigt ein Feld „Anschrift im Impressum“ — Straße, Hausnummer, Postleitzahl und Ort, eine Zeile je Angabe — und darunter, als Vorschau, den echten Absatz aus Impressum und Datenschutzerklärung (Anbieterangaben aus frontend/src/components/pages/, derselbe Baustein): GbR, Anschrift, Gesellschafter und Kontakt, so wie ein Besucher sie liest. Die Vorschau folgt dem Entwurf beim Tippen; solange der Entwurf nicht gültig ist, zeigt sie die gespeicherte Anschrift, und über dem Satz steht rot „Höchstens sechs Zeilen und 300 Zeichen, ohne Tabulator.“

Gespeichert wird erst mit „Anschrift übernehmen“, als Instanzvorgabe impressum.anschrift über PREFERENCE_GLOBAL — dieselbe Tabelle (personal.preference_defaults) wie jede andere Vorgabe für alle, aber nur in der Instanzschicht: Eine Rolle oder ein Konto hat keine eigene Anschrift, und der Server weist den Schlüssel in jeder anderen Schicht ab (NUR_INSTANZ). Ein leeres Feld löscht die Zeile; das Impressum sagt dann wieder laut, dass die Anschrift fehlt. „Entwurf verwerfen“ holt den gespeicherten Wert zurück. Ging das Speichern nicht durch, steht unter der Vorschau „Die Anschrift ließ sich nicht speichern. Versuche es noch einmal.“ — der Entwurf bleibt im Feld.

Der Hinweis unter dem Titel sagt, wer den Wert sieht: „Öffentlich, für jeden Besucher.“ Das ist der einzige Wert der Verwaltung, der ohne Anmeldung herausgeht — über GET /api/impressum/anschrift, der genau diesen Wert liefert.

Instanzname — der Name vor den Kalendern (10.10.2026)

Der Abschnitt zeigt ein Feld „Name“ (höchstens 32 Zeichen, vorbelegt mit „Denotato“, bis 11.10.2026 „GOLD“) und darunter, wie ein neuer Kalender heißt: „Neue Kalender heißen dann „Denotato · Uni“. Schon angelegte behalten ihren Namen.“ Der Name steht vor dem Namen jedes Kalenders, den Denotato bei Google und iCloud anlegt. „Name übernehmen“ schreibt ihn als Instanzvorgabe instanz.name (nur Schicht instanz, NUR_INSTANZ); ein leeres Feld zu übernehmen nimmt die Vorgabe zurück, und es gilt wieder „Denotato“. Schon angelegte Kalender behalten ihren Namen und werden weiter gefunden (kalenderNochDerselbe), so entsteht keine zweite Reihe und kein Termin zieht um. Seit dem 11.10.2026 (VA-261010-gespeicherter, Wanderung 288) speichert eine Kategorie nur den Rest ihres Zielnamens („Klausuren“); der Instanzname steht auch vor einem ausdrücklich gesetzten Zielnamen.

Blocknamen — wie Blöcke im Menü mit / heißen (12.10.2026)

Christian hat zu LX17 entschieden, dass ein Admin den Namen des LaTeX-Blocks im Menü mit / der Dokumente stellt (F10; LX-261012-namen-latex-blocks). Die Karte „Im Menü mit /“ zeigt je stellbarer Blockart ein Feld, beschriftet mit ihrem eingebauten Namen — heute nur „LaTeX-Text“ (höchstens 40 Zeichen, ohne Zeilenumbruch und Tabulator). Leer steht der eingebaute Name als Platzhalter da; er geht durch die Übersetzung, ein eingetragener Name steht in jeder Sprache so da. „Namen übernehmen“ schreibt die Felder beschnitten als Instanzvorgabe dokumente.blocknamen (nur Schicht instanz); sind alle leer, nimmt es die Vorgabe zurück. Das Menü zeigt den neuen Namen nach dem Neuladen. Welche Blockarten hier stehen, sagt STELLBARE_BLOCKNAMEN in @shared/handlers/documents/blocknamen.ts; eine weitere kommt mit einer Zeile dort, die Karte nimmt sie ohne Umbau mit.

Hochschulen — Karten und Vorschläge (VA14, N423, N427, 30.09.2026)

Welche Hochschulen ein Konto wählen kann, sind Daten, die ein Admin hier pflegt, kein Code (N423). Die erste Füllung brachten zwei Wanderungen: 198 die zwölf staatlichen Berliner Hochschulen, 294 (VA-261010-hochschulliste-berlin) acht staatlich anerkannte konfessionelle und private — EHB, KHSB, Hertie School, ESMT, Bard, CODE, MSB, PHB —, je mit Standort Berlin, aber ohne Lernplattform, Verzeichnis und Hostfreigabe, bis ein Admin den Host gemessen hat. Aus der Hochschule eines Kontos kommen Vorgaben für Ort, Mensen, Lernplattform und Vorlesungsverzeichnis; die eigene Wahl des Kontos geht immer vor. Wählen lässt sich die Hochschule in den Einstellungen (settings.md, Konto › Hochschule) und einmal auf der Übersicht (dashboard.md, „Die Frage nach der Hochschule“).

Oben steht ein Satz mit den Zahlen — „4 Hochschulen · 12 Konten mit Hochschule · 3 ohne“ — und rechts der Knopf „Neue Hochschule“.

Darunter die Karten (Musterbogen D2), ein Raster, eine Karte je Hochschule: Name, darunter Stadt und die Zahl der Konten, die sie gewählt haben, dann der Satz, den ein Konto liest („Als Vorgabe im Briefing: Wetter für Berlin-Mitte, die Mensa Süd, die Lernplattform. Was du selbst wählst, geht vor.“). Fehlt etwas, stehen darunter Marken: ausgeblendet · kein Ort · keine Mensa · keine Lernplattform · keine Vorlesungszeit · Host nicht freigegeben · Host gesperrt. Eine ausgeblendete Hochschule ist blass; wer sie trägt, behält sie, wählen kann sie niemand mehr.

„Bearbeiten“ klappt die Karte an Ort und Stelle zum Editor auf. Oben steht „Entwurf · 2 Änderungen“, darunter die Vorschau in einem getönten Kasten (E-261007-vorschau-verwaltung) — „So liest es ein Konto, das diese Hochschule wählt:“ mit demselben Satz, der dem Entwurf beim Tippen folgt. Die Felder: Name, Stadt, Kennung (etwa hu-berlin; bei einer bestehenden nur zum Lesen — „bleibt, Konten tragen sie“), der Ort für das Wetter (Name, Breite, Länge), die Mensen (Nummer bei OpenMensa und Name, je Zeile ein ✕), die Vorlesungszeiten (VA13, N508; je Zeile Winter, Sommer oder „keine“, seit dem 10.10.2026 ein freier Name wie „Herbst 2026“ (Platzhalter „Name (frei)“, höchstens 80 Zeichen, VA-261010-semesterzeiten), das Jahr, in dem das Semester beginnt, erster und letzter Vorlesungstag und ein ✕; Art oder Name muss da sein, sonst „Jede Vorlesungszeit braucht Winter, Sommer oder einen Namen.“; ein Name steht in der Vorschau und beim Konto statt „Wintersemester …“, in jeder Sprache, wie er geschrieben ist; „Vorlesungszeit hinzufügen“ schlägt das Semester nach dem letzten vor und lässt die Tage leer, nach einem Zeitraum ohne Art wieder einen ohne Art; auf dem Telefon stehen Art, Jahr und ✕ oben, der Name über die ganze Breite darunter, dann die Tage; je Semester darunter seine vorlesungsfreien Zeiten, höchstens sechs, je Zeile Grund, erster und letzter Tag und ✕, darunter „Vorlesungsfreie Zeit hinzufügen“ — seit 14.10.2026, KN-261013-einrichtung-bauen; eine Zeit ohne Grund, außerhalb der Vorlesungszeit oder überschneidend meldet „Jede vorlesungsfreie Zeit braucht einen Grund und liegt ganz in ihrer Vorlesungszeit, ohne sich mit einer anderen zu überschneiden.“), Art und Adresse der Lernplattform (Arten Moodle, ILIAS, Blackboard, Stud.IP, Canvas und andere; Stud.IP und Canvas seit VA-261010-lernplattformarten, 11.10.2026 — ihre Konten bekommen den Weg über das Kalender-Abo, nicht den Moodle-Schlüssel), Art und Adresse des Vorlesungsverzeichnisses, die Notenskala (VA-261008-notenskala, 08.10.2026; Gruppe Noten, Auswahl „1,0 bis 5,0 — kleiner ist besser“, „0 bis 20 — größer ist besser“, „Schulnoten 1 bis 6 — kleiner ist besser“ oder „0 bis 15 Punkte — größer ist besser“ (die beiden letzten VA-261010-schulnoten-1-bis-6-0, 11.10.2026), darunter „Gilt für neue Noten. Eingetragene behalten die Skala, auf der sie stehen.“) und „In der Auswahl zeigen“. Stimmt etwas nicht, sagt ein roter Satz, was — etwa „Eine Adresse beginnt mit https:// und trägt weder Port noch Anmeldung.“ oder „Zwei Vorlesungszeiten überschneiden sich oder nennen dasselbe Semester.“ Die Vorschau nennt die Vorlesungszeiten in einem zweiten Satz: „Vorlesungszeit: Wintersemester 2026/27 vom 12.10.2026 bis 13.02.2027. Eine Veranstaltung ohne eigenes Ende endet im Kalender dort; eigene Semester im Studium gehen vor.“ „Übernehmen“ speichert, „Verwerfen“ schließt ohne.

Standorte (VA-261008-standorte, 08.10.2026). Ort, Mensen, Vorlesungszeiten und Zeitzone gehören einem Standort, nicht der Hochschule (admin.standorte, Wanderung 270). Im Editor steht vor dem Ort die Gruppe „Standorte“: der Name des Standorts (leer heißt er wie die Stadt), die Zeitzone als Zone wie Europe/Paris, das Bundesland (Auswahl der sechzehn Länder oder „keine“; daraus wählt der Stundenplan die Feiertage vor, KN-261013-einrichtung-bauen), darunter die Kennung — bei einem neuen Standort „folgt dem Namen, bis der Standort gespeichert ist“, bei einem gespeicherten „bleibt, Konten tragen sie“ — und „Standort in der Auswahl zeigen“. „Standort hinzufügen“ legt einen weiteren an, mit der Zone des eigenen Kontos als Vorgabe. Ab zwei Standorten wählt ein Auswahlfeld „Standort bearbeiten“, wessen Ort, Mensen und Vorlesungszeiten darunter offen stehen; die Vorschau liest dann „So liest es ein Konto, das diese Hochschule am Standort Campus Paris wählt:“. Ein gespeicherter Standort lässt sich nur ausblenden, ein neuer mit „Neuen Standort aus dem Entwurf nehmen“ wieder entfernen. Einer bleibt immer sichtbar („Mindestens ein Standort bleibt in der Auswahl.“); ein Fehler an einem Standort nennt ihn vorn („Standort Campus Paris: …“). Die Konten wählen ihren Standort in der Hochschulwahl (settings.md).

Die Hostfreigabe steht im Editor unter den Adressen: je Host eine Zeile mit seinem Zustand — frei — Denotato ruft ihn ab, gesperrt oder noch nicht freigegeben — und den Knöpfen „Freigeben“ und „Sperren“. Eine fremde Adresse ruft Denotato erst ab, wenn ihr Host frei ist (N423). Die Freigabe gilt sofort und für jede Hochschule auf diesem Host, deshalb wartet sie nicht auf „Übernehmen“.

Vorschläge (Musterbogen E1, N427) stehen als eigene, breite Karte vor allen anderen, aber nur, wenn es welche gibt. Ein Vorschlag entsteht, wenn ein Konto eine Dienstadresse speichert — heute die Adresse seines Moodle unter Zugangsdaten —, deren Host noch keine Freigabe hat. Je Host eine Zeile: der Host, darunter „Moodle · von 2 Konten · seit 29.09.2026“, dann „Freigeben“, „Ablehnen“ und das Feld „Einer Hochschule zuordnen“. Freigeben und Ablehnen setzen die Hostfreigabe wie im Editor, und die Zeile verschwindet. Zuordnen öffnet den Editor der gewählten Hochschule (oder einer neuen) mit der Adresse als Lernplattform schon im Entwurf; gespeichert ist damit noch nichts.

Die Verwaltung sieht nur die Zahl der Konten und seit wann, nie welche. Die Zeilen in admin.hostvorschlaege nennen ein Konto und bleiben deshalb nicht länger als nötig: Ist über den Host entschieden, werden sie gelöscht, und wer die Adresse wieder entfernt oder auf einen freien Host umstellt, nimmt seinen Vorschlag mit. Adressen, die vor dem 30.09.2026 gespeichert wurden, erscheinen erst, wenn ihr Konto sie einmal neu speichert — die Zugänge sind verschlüsselt, und die Verwaltung liest sie nicht nach.

Vom Modell gelesen (VA19, N502) ist die zweite breite Karte, nach den Vorschlägen und nur, wenn der Rückfall per Sprachmodell schon etwas gelesen hat. Sie zählt aus beiden Zwischenspeichern — dem des Vorlesungsverzeichnisses (VA08) und dem des Speiseplans (VA18) — je Rechner und Quelle: der Rechner, darunter „Vorlesungsverzeichnis · Freie Universität Berlin · zuletzt 04.10.2026“ (oder „keiner Hochschule zugeordnet“, wenn weder Verzeichnis noch Lernplattform einer Hochschule dort stehen), dann „52 Lesungen · 2 Ausfälle · 3 verworfen · 158-mal ausgeliefert“. Eine Lesung ist ein Aufruf des Modells für einen neuen Seitenstand; Auslieferungen zählen auch die Treffer im Zwischenspeicher. Die Liste steht nach Lesungen geordnet, die meisten oben.

Ab der Schwelle — fehlerfreie Lesungen, Ausfälle zählen nicht — trägt die Zeile die Marke „Eigener Wandler lohnt“, und die Karte der zugehörigen Hochschule trägt „Eigener Wandler lohnt: Rechner, n Lesungen“. Die Schwelle ist der Instanzwert rueckfall.anstoss (Vorgabe 50); der Hinweis oben auf der Karte nennt ihn und sagt als Vorschau, wie viele Rechner heute darüber stehen. Gestellt wird er unter Instanzwerte, Gruppe „Rückfall per Sprachmodell“ (N508), nicht auf dieser Karte. Die Regel liegt in @shared/handlers/einrichtungen/lesezahl.ts. Fehlt ein Zwischenspeicher, weil seine Wanderung noch nicht eingespielt ist, bleibt seine Zahl leer.

„Moodle fragen“ (VA15, Schritt 1, N485) steht auf jeder Karte, deren Lernplattform ein Moodle ist, neben „Bearbeiten“. Der Server stellt dem Moodle die öffentliche Frage tool_mobile_get_public_config — ohne Anmeldung, ohne Konto, ohne Merkmal, und nur, wenn der Host frei ist. Danach steht auf der Karte über den Knöpfen „Moodle gefragt So., 04.10., 08:31 · Fassung 4.3.2 · im Wartungsmodus“ (Fassung und Wartung nur, wenn Moodle sie nennt), darunter ein Satz zum Dienst — „Webdienste und der Dienst der App sind an; die App meldet im Browser an.“ — und die Marken „Wege zum Schlüssel“: Browser, Passwort, oder „Kein Weg zum Schlüssel erkannt“. Kam keine Auskunft, nennt der Satz den Grund mit Host: nicht gefragt, weil der Host nicht freigegeben ist; die Adresse zeigt nicht ins öffentliche Netz; nicht erreichbar; „antwortete mit HTTP 503“ (auch eine Weiterleitung zählt so); keine Auskunft in der Antwort (kein Moodle oder ein zu altes); Moodle hat die Frage abgelehnt. Der Knopf heißt danach „Erneut fragen“.

Die Auskunft steht an der Einrichtung (Spalte moodle_auskunft, Wanderung 223, N508) und übersteht einen Neustart; die Karte zeigt sie, bis jemand erneut fragt.

Darunter, auf jeder Karte mit Moodle, das Kästchen „Studierende dürfen in Moodle selbst einen Schlüssel erzeugen“ (VA15, Schritt 2). Die Auskunft verrät das Recht moodle/webservice:createtoken nicht; der Admin vermerkt es. Ein Klick gilt sofort, ohne „Bearbeiten“, wie die Hostfreigabe. Der Satz darunter sagt, was der Vermerk bewirkt: gesetzt „Konten dieser Hochschule bekommen den Weg über die Schlüsselseite von Moodle.“, sonst „Ohne den Vermerk zeigt Denotato die Schlüsselseite nicht an.“ Scheitert das Setzen, erscheint der Hinweis darunter. Seit dem 07.10.2026 greift der Vermerk: Konten, die diese Hochschule gewählt haben, sehen in der Moodle-Kachel unter Zugangsdaten den Knopf „Schlüssel in Moodle holen“ (docs/seiten/settings.md). Sagt die letzte Auskunft, dass Webdienste oder der Dienst der Moodle-App abgeschaltet sind, geht das vor: Die Konten lesen dann einen Satz, warum Moodle leer bleibt, und keinen Knopf.

Bekommt die Hochschule beim Bearbeiten eine neue Adresse der Lernplattform, leert der Server Auskunft und Vermerk: Sie galten einem anderen Moodle. Wer nur Name, Ort oder Mensen ändert, behält beides. Form und Regel für die Wege liegen in @shared/handlers/einrichtungen/moodleauskunft.ts, die Frage in packages/backend/src/sync/moodleauskunft.ts.

Fächer — die Liste für das Studium (VA13, 07.10.2026)

Welche Fächer ein Konto im Studium einem Modul oder Thema geben kann, war bis Wanderung 258 ein Datenbanktyp mit fünf Werten. Seitdem ist es eine Liste in admin.faecher, und nur ein Admin legt hier Fächer an; ein Konto wählt aus dem, was sichtbar ist. Gebaut wie die Hochschulen darüber (Faecherpflege.tsx):

• Oben die Zahl („6 Fächer · 1 ausgeblendet“) und „Neues Fach“.
• „So sieht es ein Konto“ — die sichtbaren Fächer als Pillen, in der Reihenfolge, in der sie im Formular des Studiums stehen. Die Pille ist dieselbe Zelle wie in den Tabellen des Studiums (renderCell, Art badge), nicht eine nachgebaute.
• Eine Zeile je Fach, nach Reihenfolge, dann Wort, getrennt von Haarlinien (seit 10.10.2026, ES-261010-restliche-kartenraster; vorher ein Raster aus Karten — eine Pille, eine Kennung und „Bearbeiten“ tragen keine Kachel, und die Reihenfolge ist hier die Aussage, Guide §15.1): Die Pille ist die Überschrift (ein Name darüber sagte dasselbe Wort zweimal), daneben Kennung und Reihenfolge; ausgeblendete Fächer blass mit „Ausgeblendet — steht nicht zur Wahl.“
• „Bearbeiten“ und „Neues Fach“ öffnen einen Entwurf über die ganze Breite: Wort, Kennung (nur beim Anlegen; sie folgt dem Wort, bis jemand sie selbst ändert), Ton mit Farbmuster (Grau, Blau, Grün, Gelb, Rot — die Zustandstöne aus FACHTOENE), Reihenfolge und „In der Auswahl zeigen“. Darüber die Vorschau des Entwurfs in einem getönten Kasten: die Pille, und an welcher Stelle der Auswahl das Fach stünde — oder dass es nicht zur Wahl steht und Zeilen, die es tragen, es grau zeigen. Erst „Übernehmen“ schreibt; „Verwerfen“ schließt ohne Anfrage.
• „Andere“ lässt sich nicht ausblenden — das Kästchen ist gesperrt, ein Satz sagt warum: Dorthin fällt, was kein anderes Fach trägt. Der Server prüft dasselbe (istFach, CHECK in Wanderung 258).

Gelöscht wird nicht: Module und Themen tragen die Kennung, und ein gelöschtes Fach ließe sie ohne Fach zurück. Ausblenden nimmt es aus der Auswahl; wer es schon trägt, behält es. Lehnt der Server ab, steht seine Meldung als Satz unter dem Entwurf (fach_ungueltig_error, fach_unbekannt_error).

Grundliste (Wanderung 293, VA-261010-studienfaecher, 11.10.2026): Zu den fünf ersten Fächern trägt die Wanderung hundert gängige nach der Fächersystematik des Statistischen Bundesamts ein, neutral und mit Reihenfolge 100 — nur, wo Kennung und Wort noch fehlen; ein Fach, das ein Admin schon angelegt oder ausgeblendet hat, bleibt, wie es ist. Danach werden sie hier gepflegt wie jedes andere. Wer im Studium sein Fach nicht findet, meldet es mit „Mein Fach fehlt“; die Meldung kommt als Wunsch unter den Rückmeldungen an, mit dem Umstand anlass=fach-fehlt.

Tutor — Aufgabenarten und Fehlerklassen je Fach (VA-261007-tutor-aufgabenarten-je, 08.10.2026)

Unter dem Entwurf eines bestehenden Fachs steht der Abschnitt „Tutor“ (Tutorlisten.tsx); ein neues Fach bekommt ihn erst nach dem Anlegen. Er speichert getrennt vom Fach.

• Erbt das Fach, steht dort „Erbt die Listen von „Andere“ …“, die Wörter beider Listen in einer Zeile (die Prüfaufgabe mit Zusatz) und „Eigene Liste anlegen“. Das legt einen Entwurf als Abschrift der geerbten Listen an; geschrieben wird erst mit „Liste übernehmen“. „Andere“ selbst erbt nie und zeigt gleich den Editor.
• Der Editor zeigt Aufgabenarten und Fehlerklassen als nummerierte Listen: Pfeile verschieben einen Eintrag, darunter Wort und „Beschreibung fürs Modell“, die Kennung klein, Haken „sichtbar“ und bei Arten „Prüfaufgabe“, dazu „Herausnehmen“. Ausgeblendetes steht blass. Die Kopfzeile zählt den Entwurf („Entwurf · 2 Änderungen“); „Änderungen verwerfen“ holt den gespeicherten Stand zurück.
• Hinzufügen wählt einen Katalogeintrag, den die Liste noch nicht trägt, oder „Neuer Eintrag …“ mit Wort, Kennung (folgt dem Wort) und Beschreibung. Eine Kennung, die der Katalog schon hat, wird abgewiesen mit dem Hinweis, den Eintrag in der Auswahl zu nehmen. Höchstens 30 Einträge je Liste — jede geht ganz in den Auftrag an das Modell.
• Wort und Beschreibung gehören dem Katalog. Wer sie an einem bestehenden Eintrag ändert, sieht am Eintrag, dass die Berichtigung in jedem Fach gilt, das die Kennung nutzt; der Server schreibt sie beim Speichern in admin.aufgabenarten bzw. admin.fehlerklassen. Die Kennung bleibt, Aufgaben und Versuche tragen sie. Gelöscht wird aus dem Katalog nie; „Herausnehmen“ nimmt nur aus der Liste des Fachs.
• Ohne sichtbare Prüfaufgabe wird kein Thema fertig. Fehlt sie, sagt ein Satz, welcher Haken fehlt, und „Liste übernehmen“ ist gesperrt; der Server weist dasselbe ab (tutorliste_ohne_pruefaufgabe_error). Mehrere Prüfaufgaben sind erlaubt, eine bestandene genügt.
• „Eigene Liste entfernen“ (nicht bei „Andere“) fragt einmal nach; danach erbt das Fach wieder von „Andere“, der Katalog bleibt.

Gruppen — anlegen, berechtigen, aufnehmen (A05, 15.10.2026)

Bis hierher legte nur das Saatskript Gruppen an. Die Kategorie steht zwischen Rollen und Konten, hinter derselben Fähigkeit wie die Wege /api/gruppen/* (settings.global_default).

• Oben zwei Felder, Name und Schlüssel, und „Gruppe anlegen“. Der Schlüssel folgt dem Namen (klein, Umlaute ausgeschrieben, alles andere ein Unterstrich), bis man ihn selbst ändert. Ein ungültiger Schlüssel sagt in einem Satz, wie einer aussieht; ein vergebener „Diesen Schlüssel trägt schon eine Gruppe.“
• Darunter je Gruppe eine Zeile unter einer Haarlinie: Name, darunter der Schlüssel, rechts ein Knopf mit der Zahl der Mitglieder, der die Mitglieder aufklappt. Unter dem Kopf die Rechte, je eines in Schreibmaschinenschrift mit „Nehmen“, und darunter die Auswahl „Recht geben …“ mit den Fähigkeiten, die die Gruppe noch nicht trägt.
• Aufgeklappt die Mitglieder mit Bild, Anzeige- und Benutzername und „Entlassen“, darunter das Suchfeld Aufnehmen: Es sucht im Browser in der Kontenliste von /api/rechte/konten (dieselbe Hürde, darum kein eigener Suchweg), nach Anzeige- und Benutzername, höchstens acht Treffer, nie wer schon drin ist; je Treffer „Aufnehmen“.
• Was nur der Meta-Server vergibt (N144) — settings.global_default, memories.sensitive, dev.* — steht nicht zur Wahl und trägt statt „Nehmen“ den Vermerk „nur im Meta-Server“. Eine Gruppe, die so ein Recht trägt, zeigt ihre Mitglieder ohne „Entlassen“ und ohne Suche, mit einem Satz, warum.
• Nach jeder Änderung steht die Gruppe aus der Antwort da. Betrifft sie das eigene Konto, lädt der Zugriff neu; das Rangabzeichen des Kontos fragt neu (E22).
• Gelöscht wird nicht (Grundsatz 55).

Instanzwerte (N508, 04.10.2026)

Alle Instanzwerte der Liste in @shared/config/instanzwerte.ts, je Gruppe ein Abschnitt unter einer Haarlinie (bis 10.10.2026 eine Karte), zehn in der Folge der Liste: Bremsen, Schicht, Modell, Rückfall per Sprachmodell, begleiter, tutor, karten, Nutzungsprotokoll, gast und die Gruppe backup (B-261009-fristen-sicherung-als, 14.10.2026); unter ihrem Kopf steht ein Satz: „Meta liest diese Fristen aus der Datenbank von prod. In beta gestellt, ändern sie nur die Betriebswache von beta.“ Ihre drei Zeilen sind die Höchstalter von Wiederherstellungsprobe, Spiegel und Snapshot, in Stunden. Die vier ohne Eintrag in GRUPPENTITEL (Instanzwertpflege.tsx) tragen als Kopf den rohen Schlüssel (Punkt 60 unter „Was fehlt“). Jede Zeile trägt den Namen (@shared/config/instanztitel.ts), darunter klein den Schlüssel und woher der Wert kommt, rechts den Wert, der gilt, mit Einheit (bei einer Anzahl ohne Einheitswort). Die Herkunft heißt „ab Werk“, „gesetzt am 04.10.2026, 14:02 von Christian · Grund: …“ oder „aus der Umgebung: NAME“, dann mit „in der Tabelle steht …“, wenn dort auch etwas steht. Liegt ein Eintrag der Tabelle außerhalb der Grenzen, steht „ab Werk · der Eintrag … liegt außerhalb der Grenzen und gilt nicht“. Liegt er innerhalb, ist aber noch nicht gelesen (frisch gestellt, die Schicht hat noch nicht aufgefrischt), endet die Herkunft mit „· der Eintrag … gilt ab der nächsten Auffrischung“.

„Ändern“ öffnet unter der Zeile das Feld „Neuer Wert in Einheit“, ein Feld für den Grund (höchstens 200 Zeichen, freiwillig) und die Vorschau (Grundsatz 73): leer „Eine ganze Zahl von min bis max.“; außerhalb rot „Nur ganze Zahlen von … bis … — was darüber oder darunter liegt, wird abgewiesen, nicht gekappt.“, und „Wert übernehmen“ bleibt grau; derselbe Wert „Das gilt schon.“; mit Schalter der Umgebung „Wird gespeichert, wirkt aber erst ohne den Schalter NAME; bis dahin gilt …“; sonst „Nach dem Übernehmen gilt sofort neu statt alt.“, beim Wert ab Werk mit „Das ist die Vorgabe.“. „Vorgabe einsetzen (n)“ füllt nur das Feld.

„Eintrag löschen“ steht nur, wenn die Tabelle einen Eintrag hat (N511). Der erste Klick löscht nicht: Der Knopf heißt dann „Wirklich löschen“, „Wert übernehmen“ wird grau, und die Vorschau sagt, was danach gilt — „Danach gilt sofort Vorgabe ab Werk statt Wert.“; ist der Eintrag schon die Vorgabe, „Es gilt schon Vorgabe ab Werk; danach folgt der Wert der Vorgabe, wenn sie sich ändert.“; mit Schalter der Umgebung „Danach gilt weiter Wert aus dem Schalter NAME, ohne ihn Vorgabe ab Werk.“ Jedes Mal folgt „Wann, von wem und warum er gesetzt wurde, geht mit dem Eintrag verloren.“ Erst der zweite Klick löscht; wer tippt oder „Vorgabe einsetzen“ drückt, verlässt das Löschen wieder. Ein Eintrag, der schon fehlt, ist kein Fehler.

Nach dem Übernehmen oder Löschen zeigt die Liste den neuen Stand, ohne neu zu laden; eine Abweisung des Servers steht unter der Vorschau, „Verwerfen“ schließt das Feld.

Steht ein Schlüssel noch nicht in admin.instanzwert_grenzen oder mit anderen Grenzen als im Programm, steht statt des Knopfs „Erst nach dem nächsten Wandern zu stellen.“ — abgeglichen wird bei wandere.ts --alle (config/instanzgrenzen.ts).

Warum ein eigener Weg. Bis N508 setzte man Instanzwerte von Hand oder über Meta (N271), weil denotato_app die Tabelle nicht schreiben darf. Das bleibt so: Die Anwendung ruft admin.stelle_instanzwert (SECURITY DEFINER, Wanderung 225), die nur Schlüssel mit Grenzen in der Datenbank und ganze Zahlen dazwischen annimmt, und zum Löschen admin.entferne_instanzwert (Wanderung 228, N511), die ebenfalls nur Schlüssel mit Grenzen und ein Konto annimmt; ein DELETE direkt bleibt denotato_app verwehrt. Gelöscht gilt die Vorgabe ab Werk, und die liegt innerhalb der Grenzen. Eine überlistete Anwendung kann eine Bremse damit höchstens bis an ihre Obergrenze lockern, nicht abschalten. Wer stellen darf, entscheidet settings.global_default im Controller (instanzwerteController.ts). Die Schicht plant ihre Auffrischung Runde für Runde neu, damit auch instanz.auffrischung ohne Neustart wirkt. verify:instanzwerte, Abschnitt 7, prüft den Weg.

Oberfläche — wo die Instanz die Anordnung stellt (OE04, 15.10.2026)

Ein Verzeichnis, kein Editor: Bearbeitet wird am Ort selbst, als Entwurf mit „Übernehmen“ (Grundsatz 73, N398). Die Liste nennt jeden Ort, dessen Anordnung die Instanz stellt, gegliedert nach dem, was man sieht — die Leiste (Kontomenü, Adresszeile, feste Plätze; OE06), die Kacheln der Übersicht (OE09) und die zwölf Schirme mit Reitern (OE10), je mit Zeichen und Namen ihres Bereichs. Fehlt ein Bereich, fehlt seine Zeile.

Unter jedem Namen steht die Herkunft: „Wie eingebaut“ oder „Von der Instanz gestellt“ — Letzteres, sobald oberflaeche.reiter eine Folge des Orts trägt (beim Schirm auch eine seiner Ansichten, study/semester) oder dashboard.kacheln eine Instanzvorgabe hat. Nur dann steht „Zurücksetzen“ da; es nimmt die Vorgabe dieses einen Orts ohne Dialog zurück, die übrigen Folgen im Schlüssel bleiben. Darüber erscheint „„<Ort>“ steht wieder wie eingebaut.“ mit „Vorgabe zurückholen“, das den Wert von vorher wieder schreibt, bis zum nächsten Zurücksetzen.

„Bearbeiten“ führt an den Ort und öffnet dort den Modus: beim Schirm mit seinem Weg, bei den Kacheln die Übersicht in der Schicht „Für alle“, bei der Leiste ohne Wechsel, weil sie über jedem Schirm steht. Verlangt wird über eine kleine Ablage (components/bearbeiten/einstieg.ts), nicht über die Adresse — der Modus ist Zustand der Sitzung, und ein Lesezeichen öffnete ihn sonst bei jedem Besuch.

Welche Schirme Reiter tragen, steht in REITERSCHIRME (components/bearbeiten/orte.ts); Oberflaechenpflege.test.tsx liest jede reiterfolge="…" aus den Plugins und wird rot, wenn einer fehlt. Kein neuer Endpunkt, also kein MCP-Werkzeug (N7): geschrieben wird über die Vorgaben der Einstellungen wie im Modus selbst.

Gestaltung — welches Stilpaket Denotato zeichnet (17.10.2026, E-261016-admin-schalter)

Der Schlüssel ist theme.stilpaket; wie er sich auflöst und wer welche Schicht schreiben darf, beschreibt die Einstellungsseite, §4. In der Übersicht steht als Wert „Für alle: Legacy“ oder der Name, den die Instanz gestellt hat, sonst der eingebaute. Code: client/Gestaltungspflege.tsx.

Welches Paket gilt. „Ändern für“ wählt das Ziel: „alle Konten“ oder eine Rolle aus der Rollenliste. „Paket“ bietet die gebauten Pakete aus STILPAKETE an; ohne Wert steht dort „wie eingebaut (Legacy)“ für alle, „wie für alle“ bei einer Rolle. Eine Wahl schreibt sofort, für alle über setzeGlobal, für eine Rolle über setzeRolle — dieselben Wege wie jede andere Vorgabe, deshalb kein neuer Endpunkt und kein MCP-Werkzeug. „Vorgabe zurücknehmen“ steht nur, wenn am Ziel etwas gesetzt ist, und schreibt null. Steht am Ziel ein beschlossener, aber noch nicht gebauter Name, bleibt er als „{Name} (noch nicht gebaut)“ in der Auswahl, damit niemand eine leere Auswahl für „nichts gesetzt“ hält. Der Hinweis darunter sagt, was daraus folgt: Ein eigenes Theme am Konto gilt nur, wo die Vorgabe nicht Legacy ist.

Vorschau an diesem Gerät. Eine zweite Auswahl schreibt die Geräteschicht im Browser, die vor jeder Vorgabe gilt; „Vorschau beenden“ nimmt sie zurück. Sie steht nur hier, weil nur Admins und Entwickler die Verwaltung sehen — die Einstellungsseite bietet das Paket unter „nur dieses Gerät“ nicht an. Dieselbe Schicht setzt /ansehen --pakete legacy,pruefpaket für die Bilder nebeneinander.

Stufensteine — welcher Stein welche Stufe trägt (19.10.2026, NB-261019-steine-stufen-raenge)

Unter „Gestaltung“ steht die Karte Stufensteine (Stufensteinpflege.tsx). Sie pflegt den Instanzwert stufen.steine; ohne gesetzten Wert gelten Premium Diamant, Admin Rubin, Dev Tansanit. Ein Satz sagt, was der Stein bewirkt und dass zwei Stufen tauschen, wenn der gewählte Stein schon vergeben ist. Darunter je Stufe eine Zeile: der Knopf der Stufe im Kleinen, ein Punkt in ihrer Anwendungsfarbe mit deren Namen und die Auswahl aus Diamant, Rubin, Tansanit, Saphir und Goldtopas. Knopf und Punkt zeichnen aus dem gespeicherten Wert, also so, wie alle es sehen. Schlägt das Speichern fehl, steht „Nicht gespeichert“ darunter. Regel und Töne: Style-Guide §8.2 und §8.3.

Erfolge — Schwellen und Münzen (19.10.2026)

Die Karte Erfolge (Erfolgsstufenpflege.tsx) stellt je Erfolg die Schwellen der Stufen. Jede Spalte trägt oben ihre Münze mit der Nummer der Stufe; die Vorgabe sind Bronze, Silber und Gold, angehängt wird zuerst Platin, dann Steine. Seit dem 19.10.2026 ist jeder Erfolg eine runde Münze mit Emblem und Zahl, kein Sechseck mehr (Style-Guide §8.5, 2026-10-19-stein-und-muenze).

Nutzung (A45, N532, 05.10.2026)

Welche Schirme und Kernaktionen gebraucht werden. Christian: „Alle Admins, 90 Tage“ (N532) — lesen darf jedes Konto mit settings.global_default, ohne das Recht antwortet der Server mit 404.

Oben die Segmentwahl 7 Tage · 30 Tage · 90 Tage · 365 Tage, gewählt sind 30. Darunter zwei Tafeln mit Kopf aus Stein und Zeilen aus Papier wie das Protokoll der Modellaufrufe:

• Wege — Weg · Aufrufe · Nutzer · mittlere Verweildauer, nach Aufrufen geordnet, höchstens 500 Zeilen. Der Weg ist ein Routenmuster in Mono (/documents/editor/:documentId, /admin?a=nutzung); die Verweildauer ist die sichtbare Zeit je Aufruf, unter einer Minute in Sekunden („4,5 s“), darüber in Minuten („2,5 min“), ohne Messung „—“.
• Aktionen — Aktion · Anzahl · Nutzer · Dauer (Median), höchstens 1000 Zeilen. Die feste Liste trägt ihren Titel (Karte bewertet, To-do abgehakt, Notiz oder Dokument angelegt, Termin angelegt; vom 07. bis 09.10.2026 auch „Neue Navigation eingeschaltet“ und „Zur alten Navigation zurück: <Grund>“, A-261007-erneuerung-phase-3; mit dem Schalter aus dem Katalog genommen, Entscheidung ../kontext/entscheidungen/2026-10-09-neue-navigation-immer.md), alles aus dem Funktionskatalog seine Kennung (palette.befehl.papierkorb.seiten, knopf.briefing.drucken, mcp.werkzeug.dokument_lesen). Beim Serverteil folgt das Routenmuster (server.lesen · /api/documents/:documentId). Die Dauer steht nur beim Ende und Abbruch eines Ablaufs (Lernsitzung, Bearbeiten, Tutor-Gespräch, Timer), sonst „—“ (DS-261006-funktionskatalog).
• Geräte — Gerät · Sitzungen · Aufrufe · Nutzer, immer drei Zeilen in der Reihenfolge Telefon, Tablet, Schreibtisch, auch mit Null. Eine Sitzung zählt nach der Klasse, die ihre erste Handlung meldete; ihre Aufrufe zählen mit (DS-261006-geraet-umfeld). Ohne eine Sitzung mit Gerät steht „Keine Sitzung mit Gerät im gewählten Zeitraum.“
• Tageszeit — ein Raster aus sieben Zeilen (Mo bis So) und 24 Spalten, beschriftet alle drei Stunden. Jedes Feld trägt die Anwendungsfarbe mit einer Deckkraft nach seinem Anteil am vollsten Feld, ein leeres bleibt Papier; Titel und Name nennen Tag, Stunde und Anzahl („Mo 9:00 · 8“). Gezählt werden Handlungen aus dem Browser in der Ortszeit des jeweiligen Kontos, nicht die Vermerke des Serverteils. Am Telefon rollt das Raster quer. Ohne Ortszeit steht „Keine Handlung mit Ortszeit im gewählten Zeitraum.“
• Reibung — wo es hakt (DS-261006-reibung), sieben kleine Tafeln mit eigener Unterüberschrift, jede leer mit „Nichts im gewählten Zeitraum.“: Langsamste Schirme (Weg · Messungen · Median · p90, die fünf mit dem höchsten Median), Tempo im Browser (Messung · Messungen · Median · p75 · p90, die Zeilen „Kaltstart“ und „Reaktionszeit“, A45, 12.10.2026), Gezeigte Fehler (Weg · Code · Anzahl · Nutzer), Abbrüche je Ablauf (Ablauf · Begonnen · Beendet · Abgebrochen · Abbruchquote, die höchste Quote zuerst, ohne Ende „—“), Rücknahmen (Art · Schritt · Anzahl · Nutzer, Schritt „Rückgängig“ oder „Wiederholen“), Wiederholklicks (Weg · Anzahl · Nutzer) und Langsamste Routen (Route · Anfragen · Median · p90, „liest“ oder „schreibt“ hinter dem Muster, nach p90). Jede Liste zeigt höchstens 20 Zeilen. Dauern unter einer Sekunde stehen in Millisekunden („450 ms“).
• Wege und Folgen — wie Nutzer sich bewegen (DS-261006-auswertung-wege), wieder kleine Tafeln mit Unterüberschrift: Übergänge (Ausgangsweg · Zielweg · Herkunft · Anzahl · Nutzer, die Herkunft als Wort wie „Leiste“ oder „Palette“, ohne „—“), Folgen aus drei Wegen (Folge · Anzahl · Nutzer, die Wege mit „›“ verbunden, seit 10.10.2026 statt „→“), Einstiege und Ausstiege (Weg · Sitzungen · Nutzer; eine laufende Sitzung zählt mit ihrem bisher letzten Weg), Konzentration als ein Satz („Im Mittel beginnen 63 % der Sitzungen eines Kontos beim selben Gegenstand (Median 60 %, 2 Konten).“, ohne genug Konten „Zu wenige Konten mit mindestens zwei Sitzungen.“), Verweildauer (Weg · Aufrufe · sichtbar (Median) · sichtbar (p90) · aktiv (Median) · aktiv (p90)), Nie besucht als Satz mit den Routenmustern des Routers ohne Aufruf, mit Komma getrennt, und Funktionen je Schirm (Weg · Aktion · Anzahl · Nutzer). Jede Liste zeigt höchstens 20 Zeilen. Gruppen unter dem Instanzwert nutzung.mindestkonten (Vorgabe 1, 1 bis 50) fehlen; wie viele, sagt ein Satz über den Tafeln („3 Gruppen mit weniger als 2 Konten sind ausgeblendet.“). Keine Zeile nennt ein Konto.

Zahlen stehen rechtsbündig in Mono mit Tabellenziffern. Am Telefon wird jede Zeile ein Blatt, jeder Wert mit seinem Spaltennamen. Leer steht „Kein Aufruf im gewählten Zeitraum.“ bzw. „Keine Aktion im gewählten Zeitraum.“, beim Laden ein Gerüst, scheitert die Antwort, „Die Nutzung ließ sich nicht lesen.“

Woher die Zahlen kommen. Nutzungserfassung steht einmal in App.tsx und meldet jeden Routenwechsel; nutzungsprotokoll.ts macht aus der Adresse ein Routenmuster mit denselben Mustern, die der Router kennt, und behält von der Abfrage nur ?a= und ?v= (NUTZUNG_UMSCHALTER). Ein Besuch zählt seine sichtbare Zeit; ein versteckter Tab schließt ihn, die Rückkehr zählt als „wieder angesehen“ zur Verweildauer, nicht als Aufruf. Die Kernaktionen melden sich an ihrer Stelle im Code. Der erste Schirm nach dem Laden zählt, sobald die Einwilligung feststeht, nur ohne Ladedauer; vorher fehlte er (A45). Kaltstart ist die Zeit vom Laden des Dokuments bis zur ersten erfolgreichen Antwort nach dem ersten Schirm, gemeldet nur, wenn der Tab seither sichtbar war und noch kein zweiter Schirm kam. Reaktionszeit ist je Besuch die längste Zeit von einem Tippen, Klicken oder Tastendruck bis zum nächsten Bild, bei je fünfzig Interaktionen ohne die längste (die Regel von INP). Der Puffer geht alle 30 Sekunden hinaus, bei hundert Einträgen sofort und beim Verlassen per keepalive; was scheitert, ist still verloren. Was vor einem Abmelden oder Kontowechsel entstand, geht nicht mehr hinaus — sonst zählte es dem nächsten Konto.

Nur Metadaten. In der Tabelle stehen Weg, Aktion (ein Schlüssel aus einer festen Liste, ein CHECK hält sie), Zeitpunkt, Konto und die Dauer — nie ein Titel, ein Suchbegriff oder etwas Entschlüsseltes. Der Server ersetzt, was im Weg wie eine Kennung aussieht, durch :id und streicht jeden anderen Abfrageparameter, auch wenn ein verändertes Frontend ihn schickt. Nach der Frist nutzung.aufbewahrung (Instanzwert, Vorgabe 90 Tage, 7 bis 365) verdichtet der Aufräum-Zeitgeber die Einträge zu Tagessummen ohne Konto und löscht sie (ereignisseAufraeumen.ts, DS-261006-verdichten). Reicht ein Zeitraum hinter die Frist, zählen Wege, Aktionen und Geräte die Summen mit, ebenso Übergänge, Einstiege und „Nie besucht“; Mediane, Tageszeit, Reibung und alles, was eine Sitzung als Folge braucht (Folgen, Ausstiege, Konzentration, Verweildauer, Funktionen je Schirm), bleiben bei den Rohzeilen, und die Nutzerzahl ist dann eine untere Grenze.

Erfolge — ab welcher Zahl ein Erfolg eine Stufe erreicht (19.10.2026, NB-261019-soziales-erfolge)

Die Kategorie Erfolge (Zeichen stern, ?a=erfolge, in der Gruppe Instanz zwischen Gestaltung und Ideen) zeigt den Instanzwert abzeichen.stufen als Tabelle: eine Zeile je Erfolg, eine Spalte je Stufe mit dem Stein im Kopf, darunter je Quote die Menge, ab der sie zählt. Vorbefüllt mit drei Stufen (Bronze, Silber, Platin). „Übernehmen“ schreibt nur eine ganze, gültige Tabelle — jede Stufe verlangt mehr als die davor, Quoten höchstens 100; sonst steht der Grund darunter. „Stufe anhängen“ nimmt einen Stein der Leiter, den noch keine Stufe trägt (gesperrt mit Grund, bis einer gewählt ist), „Oberste Stufe entfernen“ nimmt die letzte weg; eine schon gehaltene höhere Stufe wird dann auf die oberste gekappt, ihr Datum bleibt. Christian: „Tabelle als Admin-Einstellung vorbefüllt mit den drei Stufen und zusätzliche konfigurierbar durch die diversen Materialien die wir ja schon haben.“

Ideen — Anschlüsse, die Denotato noch nicht baut (15.10.2026, KN-261015-ideenablage)

Christian am 15.10.2026: „Alle anderen abgelehnten Ideen bitte in einem Ideen-Ordner (der von Denotato Admin aus accesible ist) abspeichern und zumindest mit Logo kurzbeschreibung.“

Die Kategorie Ideen (Zeichen idee, ?a=ideen) zeigt zwei Gruppen als Karten: Zurückgestellt — was in den Zugangsdaten als Wunschknopf steht (settings.md, „Noch nicht gebaut“) — und Abgelehnt, was Musterbogen B geprüft und nicht vorgeschlagen hat (Readwise, Overleaf, Obsidian Sync, Spotify, Slack, Discord, Strava, Google Classroom, Microsoft Teams, ILIAS, Miro, Evernote). Jede Karte trägt das Zeichen aus dem eigenen Satz (keine fremde Marke, Guide §7.1), den Namen, eine Kurzbeschreibung und den Grund. Bei den zurückgestellten steht rechts, wie oft der Anschluss gewünscht wurde: gezählt aus den Rückmeldungen mit dem Umstand anschlusswunsch=<id> in den Zuständen offen, übernommen, abgelehnt und umgesetzt, gelesen über FEEDBACK_LISTE. Lässt sich die Liste nicht lesen (nur settings.global_default, kein feature.admin), steht keine Zahl da statt einer falschen Null.

Der „Ordner“ ist eine Datei im Repository, packages/shared/src/config/anschlussideen.ts; eine Idee kommt hinzu oder zieht ins Verbindungsregister um, wenn sie gebaut wird. Code: packages/plugins/src/admin/client/Ideenablage.tsx. Kein eigener Endpunkt und kein eigenes MCP-Werkzeug: Ein Modell liest die Wünsche mit rueckmeldungen_liste.

LaTeX-Fehler — was der Editor unter der Fehlerzeile erklärt (LX15, 12.10.2026)

Scheitert ein Satz im LaTeX-Editor, markiert er die Zeile des ersten Fehlers und schreibt darunter einen kurzen Satz; „Erklären“ klappt die lange Erklärung mit der Abhilfe auf. Welcher Satz zu welcher Meldung von TeX gehört, steht in personal.latex_fehlererklaerungen (Migration 297, fünfzehn eigene Sätze als Grundstock, N362). Christian am 12.10.2026: „Tabelle, Admin pflegt“ — nur hier wird sie gepflegt, mit settings.global_default wie jeder Abschnitt der Verwaltung; der Bereich LaTeX muss dafür nicht an sein. Nach Modell; der Schirm gehört dem Bereich LaTeX und kommt über dessen Klientanschluss. Ohne den Bereich fehlt die Kategorie.

• Oben die Zahl („15 Erklärungen“) und „Neue Erklärung“.
• Ausprobieren — ein Feld für eine Meldung aus einem Protokoll; darunter, welches Muster der Editor nähme, oder „Kein Muster passt“. Es ist dieselbe Regel wie im Server (passendesMuster).
• Die Liste nach Muster geordnet, je Zeile das Muster in der Schrift des Quelltexts, darunter der kurze Satz, und „Bearbeiten“. Fehlt die englische Fassung, sagt die Zeile „ohne englische Fassung“.
• Bearbeiten öffnet den Entwurf an der Stelle der Zeile: Muster, kurzer Satz deutsch und englisch, Erklärung deutsch und englisch. „Übernehmen“ schreibt, „Verwerfen“ schließt, „Löschen“ fragt einmal und ist endgültig; danach zeigt der Editor für diese Meldung den Text von TeX.

Das Muster ist Text der Meldung, in dem … für beliebig viel steht — kein regulärer Ausdruck, damit ein Muster den Server nicht aufhalten kann. Groß- und Kleinschreibung und mehrfacher Leerraum zählen nicht. Passen mehrere, gilt das mit den meisten festen Zeichen. Es braucht außer … mindestens drei feste Zeichen, und jedes Muster gibt es einmal.

LaTeX-Grenzen — PDF-Sätze je Tag nach Abo-Stufe (LX25, 13.10.2026)

Wie viele PDF-Sätze ein Konto am Tag starten darf, hängt an seiner Abo-Stufe — derselbe Gedanke wie die Kontingente des Begleiters (N224) und des Tutors (N421). Gezählt wird jeder begonnene Satz, auch ein gescheiterter; ein doppelter Klick, den die Warteschlange abweist, zählt nicht. Der Tag ist der des Kontos und endet um seine Mitternacht. Über der Grenze antwortet der Satzweg mit 429, und der Editor sagt, dass es ab Mitternacht wieder geht (latex-text-editor.md, „Sätze je Tag“). Die letzte Kategorie, nach LaTeX-Fehler; der Schirm gehört dem Bereich LaTeX und kommt über dessen Klientanschluss.

• Oben ein Satz über die letzten dreißig Tage: wie viele Sätze, wie lange einer im Mittel lief und der stärkste Tag eines einzelnen Kontos — oder „noch nichts gesetzt“.
• Je Stufe (Frei, Premium, Admin, Dev) eine Zeile: der Name, bei einer Stufe, die noch kein Admin gestellt hat, das Abzeichen Platzhalter; ein Zahlfeld, „ohne Grenze“ und „Übernehmen“. Bei einem Platzhalter heißt der Knopf „Platzhalter übernehmen“ und schreibt die Zahl fest, ohne sie zu ändern.
• Die Vorschau unter dem Namen geht mit der Eingabe mit: „bei voller Ausnutzung etwa 15 Min. Satzzeit je Konto und Tag“ — Grenze mal mittlere Dauer. Ohne Messung steht „noch nicht gemessen“, ohne Grenze, dass die Warteschlange jedes Konto ohnehin auf einen Satz zugleich begrenzt.

Die Platzhalter ab Werk sind großzügig und mit Absicht nicht gemessen: Frei 500, Premium 2000, Admin 5000, Dev ohne Grenze (SATZGRENZEN_AB_WERK in latex/shared/satzgrenzen.ts). Eine Zahl geht von 1 bis 100 000. Gestellt wird in admin.latex_satzgrenzen mit settings.global_default; fehlt eine Zeile oder ist sie unlesbar, gilt der Platzhalter.

Modell — Kontingente, Schätzung und Protokoll (KI02)

Zuerst die Zusammenfassung (OE-261015-admin-neu-ordnen, seit dem 16.10.2026): Offen steht nur der Monat der Instanz. Jeder andere Teil — Kontingent je Stufe, Modellwahl, Modell je Anlass, Denkraum, Schreibprotokoll, Gesprächsverlauf, Von selbst melden, Instanzwerte und Protokoll — steht zugeklappt als eine Zeile: Titel und darunter die geltenden Werte in einem Satz (etwa „Fragen am Tag: Frei 3 · Premium 20“ oder „Inhalt bleibt 90 Tage“). Ein Tippen auf die Zeile öffnet die Tafel, die unten beschrieben ist; zugeklappt holt sie nichts. Der Baustein ist Sammelabschnitt (frontend/src/components/ui), die Sätze stehen in begleiter/client/modellzusammenfassung.ts.

Oben zeigt ein Ring den Verbrauch der ganzen Instanz im laufenden Monat gegen ihren Monatsdeckel. Unter dem Ring steht das Vorgabemodell der Instanz (Zeile „Vorgabemodell“ der Modellwahl, Wanderung 260; DENOTATO_MODEL_NAME nur, wenn die Datenbank nichts sagt) und wofür es gerufen wird: für jeden Anlass außer der freien Frage, der in „Modell je Anlass“ kein eigenes Modell hat, und für die freie Frage nur, wenn der Vorab-Agent nichts Brauchbares wählt und die Vorgabe nicht über der Obergrenze der Stufe liegt — sonst antwortet das Modell der Obergrenze (KI11). Ist er aus, wird sie für jeden Anlass gerufen, für die freie Frage mit derselben Kürzung (KI09, KI11). Darunter steht je Abo-Stufe eine bearbeitbare Zeile mit freien Fragen pro Tag, Kontextzeichen, seit KI88 (N528, Wanderung 240) „Zeichen Überblick“, Antwortzeichen, den Runden zum Nachlesen (KI14, N330) und dem Monatsbetrag. „Zeichen Überblick“ ist die Grenze, auf die der Überblick vor einer freien Frage und einer Erklärung gekürzt wird (KI70); er zählt nicht gegen den Kontext (KI79), und Kopf, Datum und Verbindungsstand bleiben auch darüber. Ab Werk gleich dem Kontext der Stufe; 0 heißt nur dieser feste Kern. Die Schätzung „höchstens je Konto im Monat“ rechnet mit ihr. Die Runden sagen, wie oft das Modell vor der Antwort höchstens ein Werkzeug ruft: bei jeder freien Frage mit den Werkzeugen ihres Bereichs (KI19), dem Gedächtnis und dem ganzen Katalog der MCP-Werkzeuge (KI23), bei „Erklär mir das“ (KI14) und seit KI36 bei den Angeboten der Eule und beim Anstoß — diese drei nur mit den lesenden Werkzeugen des Katalogs. Ab Werk gelten seit dem 05.10.2026 frei 4, premium 8, admin und dev 8 (KI69, N519; vorher frei 2 und premium 4); 0 heißt, das Modell bekommt gar kein Werkzeug. Unter den Zellen jeder Stufe stehen seit dem 30.09.2026 (KI33, N421, Wanderung 196) die Anlässe des Tutors mit eigenem Tagesdeckel — Bewertung vorschlagen, Hinweis geben, Aufgabe vorschlagen und seit Tutor-Punkt 2 Foto oder PDF abschreiben (ab Werk 10 am Tag, 4000 Zeichen) — je mit „am Tag“ (samt Haken „ohne Grenze“), „Zeichen Antwort“, seit Tutor-Punkt 33 „Token Antwort“ und seit KI44 „Zeichen Frage“, darunter der Werkswert („ab Werk 40 am Tag, 1200 Zeichen, 1200 Token, Frage bis 8000 Zeichen“). „Token Antwort“ ist der Raum, den das Modell für seine Antwort bekommt (max_tokens, dazu der Denkraum des Aufwands), getrennt von den Zeichen, auf die der Text danach gekürzt wird: Token sind keine Zeichen, und bei einem Modell mit Denkraum zählt das Nachdenken gegen denselben Raum. Leer heißt ab Werk; eine Stufe, die den Wert nie gesetzt hat, bleibt gültig. Gespeichert werden sie in admin.abo_kontingente.anlassgrenzen; fehlt dort ein Anlass, gilt der Werkswert des Registers. Tageszähler, Lage und die Schätzung „höchstens je Konto im Monat“ rechnen mit dem Wert der Stufe, geschickt wird nur, was vom Werkswert abweicht. Gespeichert wird immer die ganze Zeile. Feste Obergrenzen fangen Tippfehler ab: 1000 Fragen am Tag, 200000 Zeichen Kontext, ebenso 200000 Zeichen Überblick, 32000 Zeichen Antwort, 16 Runden und 100000 Euro-Cent im Monat — für die Anlässe des Tutors dieselben 1000 Aufrufe und 32000 Zeichen, dazu 64000 Token. Der nächste Modellaufruf liest die neuen Werte ohne Zwischenspeicher.

Die Grenze der Frage (KI44, N501) gilt für jeden Anlass, nicht nur für die vier mit eigenem Deckel: wie viele Zeichen eine Frage haben darf, bevor sie die Regelfassung bekommt, „Die Frage ist länger, als deine Stufe erlaubt.“, ohne Ruf und ohne Kosten. Die übrigen Anlässe — freie Frage, Erklärung, die Eulenangebote und die anderen — stehen eingeklappt unter dem Aufklapper „Grenze der Frage je Anlass, alle ab Werk“ (oder „…, 3 anders als ab Werk“); jedes Feld trägt den Anlass als Namen und darunter „ab Werk 500, höchstens 2000“. Höchstens gilt das Vierfache der Zahl ab Werk; das ist dieselbe Schranke, die die Routen schon vorher als Schutz vor Missbrauch hielten, und sie bleibt dort. In anlassgrenzen kann ein Eintrag Deckel, Antwort und Token samt Grenze der Frage tragen oder nur die Grenze der Frage; fehlt sie, gilt die Zahl ab Werk. Der Server prüft eine Frage gegen die Grenze der Stufe des Kontos, kürzt die Fortsetzung nach „Ausführen“ auf sie, die Lage meldet sie als grenzeEingabeZeichen, und die Schätzung rechnet mit ihr. Der Schirm des Begleiters nimmt so viele Zeichen an, wie die Stufe erlaubt; die Ecke der Eule bleibt bei 500 (KI51).

Jede Zelle prüft beim Tippen (KI44): Passt eine Zahl nicht in ihre Spanne, steht unter ihr „Trag eine ganze Zahl von 1 bis 1.000 ein.“ (beim Monatsbetrag „Trag einen Betrag über null bis 1.000,00 € ein, mit höchstens zwei Stellen nach dem Komma.“), das Feld ist als ungültig markiert, und „Speichern“ ist gesperrt, bis alle Zellen passen. Ein Fehler in einer eingeklappten Grenze der Frage klappt den Aufklapper auf. Weist der Server die Zeile dennoch ab, steht hinter „Das Kontingent wurde nicht gespeichert.“ sein Grund — etwa „Die Grenze der Frage liegt über dem Höchstwert ihres Anlasses.“ oder „Tagesdeckel und Antwortgrenze lassen sich nur für Anlässe mit eigenem Deckel setzen.“; die Route schickt ihn im Detail der Antwort. Die Tabelle misst ihre Karte, nicht das Fenster (KI27): neben der Kategorienleiste bleibt sie in der Karte, unter Telefonbreite wird jede Stufe ein Blatt. Vorgabe, Protokoll und Filter nennen Modelle mit dem Namen der Leiter („Sonnet 5“), nicht mit ihrer Kennung; eine Kennung außerhalb der Leiter bleibt, wie sie ist.

Die Spalte „höchstens je Konto im Monat“ rechnet alle Anlässe des Begleiters ein. Je Anlass und Modell nimmt sie nach mindestens zwanzig brauchbaren Aufrufen die gemessenen Token je Zeichen aus den letzten 28 Tagen — nur mit genau dem Modell, mit dem sie gemessen wurden —; vorher rechnet sie konservativ mit Listenpreisen. Die freie Frage rechnet sie mit dem teuersten Modell, das der Vorab-Agent bis zur Obergrenze der Stufe wählen kann, samt dem Nachdenken seines höchsten Aufwands, oder mit der Vorgabe, wenn die teurer ist und nicht über der Obergrenze liegt; dazu je Frage ein Ruf des Vorab-Agenten. Weil die freie Frage „Erklär mir das“ mitträgt und das nachliest, rechnet sie jeden Kandidaten mit den Runden der Stufe: einen Ruf je Runde und einen für die Antwort, jeder mit allen Werkzeugen, die es gibt, und je voriger Runde der Antwortgrenze und einem gekürzten Ergebnis dazu (KI14). Ist er aus, rechnet sie die freie Frage mit dem Rückfall: der Vorgabe oder, liegt die über der Obergrenze der Stufe oder außerhalb der Leiter, dem Modell der Obergrenze mit ihrem Aufwand (KI09, KI11) — und, hat die Stufe Runden, zusätzlich mit dem Rückfall, angehoben auf das Mindestmodell mit Werkzeugen; der teurere zählt (KI69). Alle anderen Anlässe rechnen mit der Vorgabe, und zwar seit Tutor-Punkt 33 mit ihrem Raum in Token, nicht mehr mit den Zeichen der Antwort. Angezeigt werden der rohe Betrag bei voller Ausnutzung und der wirksame Betrag nach Monatsbetrag der Stufe und Deckel der Instanz; ein Satz unter jeder Stufe nennt Modell und Aufwand der freien Frage und das Modell des Vorab-Rufs, und die Grundlage unter der Tabelle nennt je Anlass und Modell, woher die Zahlen kommen.

Zwischen Kontingent und Instanzwerten steht die Modellwahl (KI06, N302). Ihre erste Zeile ist seit dem 07.10.2026 das Vorgabemodell (KI-261007-modell-je-anlass, Wanderung 260): das Modell, das jeder Anlass ohne eigenes ruft und auf das der Rückfall der freien Frage fällt. Ab Werk Sonnet 5.5; die Zeile trägt immer ein Modell und nie einen Aufwand, darum fehlt dort „aus“. Darunter steht der Vorab-Agent: welches Modell der Leiter — Haiku 5.5, Sonnet 5.5, Opus 5.5, Fable 5.1 — vor jeder freien Frage wählt, mit welchem Modell und Aufwand sie beantwortet wird, oder „aus"; dann beantwortet das Vorgabemodell jede Frage. Ab Werk wählt Haiku. Seine Anweisung sagt: Opus 5.5 nur für schwere Fragen (mehrschrittig, ein Beweis, eine Abwägung über viele Quellen), sonst Sonnet oder Haiku. Wählt er nichts Brauchbares oder ist er aus, gilt für die freie Frage der Rückfall: die Vorgabe, gekürzt an der Obergrenze der Stufe (KI11, N325). Mit diesem Rückfall rechnet auch die Budgetlage der freien Frage ihren kleinsten Vorbehalt. Darunter steht je Abo-Stufe die Obergrenze: bis zu welchem Modell und welchem Aufwand die Fragen dieser Stufe kommen, leer heißt ohne Grenze. Ab Werk gilt für „frei" Sonnet 5.5 mit mittlerem Aufwand, für „premium" Opus 5.5 mit hohem, für Admin und Entwicklung seit dem 07.10.2026 Opus 5.5 ohne Aufwandsgrenze (vorher keine Grenze). Eine Grenze, die ein Admin schon gesetzt hatte, ließ Wanderung 260 stehen.

Zwischen Vorab-Agent und Stufen steht seit dem 05.10.2026 das Mindestmodell mit Werkzeugen (KI69, N519, Wanderung 234): Geht mit einer freien Frage ein Werkzeug des Katalogs oder ein Nachlesewerkzeug hinaus und hat die Stufe Runden, antwortet sie mindestens mit diesem Modell — auch wenn der Vorab-Agent kleiner wählt oder der Rückfall greift —, gedeckelt durch die Obergrenze der Stufe. Eine Frage ohne Werkzeuge wählt wie bisher. Ab Werk gilt Sonnet 5.5; „aus" schaltet die Anhebung ab. Wie der Vorab-Agent hat die Zeile keinen Aufwand: Die angehobene Wahl behält ihren, soweit das neue Modell ihn kennt, sonst den kleinsten. Unter der Auswahl nennt die Vorschau je Stufe, was dann wirklich gilt, etwa „Mit Werkzeugen mindestens: Frei Sonnet 5.5 · Premium Sonnet 5.5 · Admin Sonnet 5.5 · Dev Sonnet 5.5“; sie rechnet schon den gewählten, noch nicht gespeicherten Wert. Die untere Schranke der Budgetlage bleibt der Rückfall ohne Anhebung, weil eine Frage ohne Werkzeuge mit ihm läuft.

Eine geänderte Zeile zeigt ein Feld für den Grund, „Speichern" und „Verwerfen"; unter jeder Zeile steht, wer sie wann aus welchem Grund gesetzt hat. Der Vorab-Agent bekommt nur die Frage und die Länge des Kontexts als Zahl, nie den Kontext selbst (N224, N271), und wird nur vor freien Fragen gerufen.

Unter der Modellwahl steht seit dem 07.10.2026 die Karte „Modell je Anlass“ (KI-261007-modell-je-anlass, Wanderung 260, Route BEGLEITER_ANLASSMODELL). Ihr Hinweis sagt, dass die freie Frage der Vorab-Agent wählt und hier die festen Aufträge stehen, Preise je Million Token. Je Anlass mit eigenem Modell — Bewertung, Hinweis, Aufgabe vorschlagen, Briefing, „Erklär mir das“ und die übrigen festen Aufträge; nicht, was als freie Frage zählt — steht eine Zeile mit dem Namen, der Auswahl „Vorgabe (Sonnet 5.5)“ oder einem Modell der Leiter, bei einem Modell mit Aufwand einer zweiten Auswahl („kleinster Aufwand“ oder eine Stufe) und dem Preis des gewählten Modells, etwa „2 $ hin · 10 $ zurück“; bei „Vorgabe“ der Preis des Vorgabemodells. Darunter steht, wer die Zeile wann aus welchem Grund gesetzt hat. Eine geänderte Zeile zeigt Grund, „Speichern“ und „Verwerfen“; der nächste Ruf des Anlasses nimmt das neue Modell. „Vorgabe“ speichert ein leeres Modell — zurückgesetzt wird so, nicht durch Löschen. Auf dem Telefon stehen die Felder einer Zeile untereinander. Die Schätzung je Stufe rechnet die Anlässe weiter mit dem Vorgabemodell, nicht mit ihrem eigenen.

Darunter steht seit dem 30.09.2026 die Karte „Denkraum" (Tutor-Punkt 33, N370, Wanderung 201). Sie sagt in zwei Sätzen, dass ein Aufruf, der mit mehr Aufwand denkt, Raum zum Nachdenken über die Antwort hinaus braucht, und dass mehr Raum schweren Fragen gründlichere Antworten gibt, aber jeden Ruf im schlimmsten Fall teurer macht. Darunter steht je Stufe der Aufwandsleiter ein Feld „Aufwand niedrig, Token zum Nachdenken" bis „Aufwand höchster, …", ab Werk 0, 2048, 4096, 8192 und 16384, erlaubt 0 bis 64000. max_tokens eines Aufrufs ist sein Raum der Antwort plus dieser Wert, und der Vorbehalt vor dem Ruf rechnet dieselbe Summe; ohne Aufwand kommt nichts dazu. Unter den Feldern steht „Daraus folgt für die freie Frage je Stufe:" und je Abo-Stufe eine Zeile mit dem Aufwand ihrer teuersten freien Frage, ihrem max_tokens und dem, was ein Konto der Stufe höchstens im Monat verbraucht — etwa „Frei · Aufwand mittel: bis 2.448 Token je Ruf, höchstens 0,50 € im Monat". Tippt man andere Zahlen, rechnet die Vorschau nach, sobald das Tippen ruht, und wartet, solange ein Feld keine gültige Zahl trägt; eine Zahl außerhalb der Grenzen nennt die Grenzen und sperrt „Speichern". Wie beim Schreibprotokoll stehen darunter, wer den Denkraum wann aus welchem Grund gesetzt hat (oder „Werte ab Werk"), ein Feld für den Grund, „Speichern" und „Verwerfen"; gespeichert werden immer alle fünf Werte zugleich. Sie liegen in admin.begleiter_werte; fehlt eine Zeile oder ist sie unbrauchbar, gilt der Wert ab Werk, und die Frage läuft weiter.

Unter dem Denkraum steht die Karte „Schreibprotokoll" (KI28, N395). Sie sagt in einem Satz, wofür das Schreibprotokoll des Begleiters da ist und was nach der Frist geschieht, und darunter steht ein Feld „Inhalt behalten, Tage", ab Werk 90, erlaubt von 1 bis 3650. Unter dem Feld steht, wie viele Einträge aller Konten die Frist heute leeren würde; tippt man eine andere Zahl, rechnet die Vorschau sie nach, sobald das Tippen ruht, und sagt, wenn sie sich nicht lesen ließ — Speichern geht dann trotzdem. Eine Zahl außerhalb der Grenzen nennt die Grenzen und sperrt „Speichern". Wie bei der Modellwahl erscheinen nach einer Änderung ein Feld für den Grund, „Speichern" und „Verwerfen", und darunter steht, wer die Frist wann aus welchem Grund gesetzt hat. Nach der Frist verliert ein Eintrag Eingabe, Stand davor, Stand danach und Gegenzug; Werkzeug, Weg, Ausgang und Zeitpunkt bleiben, Rückgängig geht nicht mehr. Geräumt wird einmal am Tag vom Zeitgeber denotato-schreibprotokollraeumung, der ins Löschprotokoll schreibt; die Änderungsliste im Begleiter behandelt eine Zeile jenseits der Frist schon vorher als abgelaufen.

Darunter steht seit dem 04.10.2026 die Karte „Gesprächsverlauf" (KI47, N501). Ihr Satz sagt die Folge: Ein Gespräch, das so lange keine neue Frage bekommt, geht ganz und ist nicht zurückzuholen; Briefingabsätze und Anstöße gehen nach sieben Tagen; geräumt wird einmal am Tag. Darunter steht dasselbe Feld wie beim Schreibprotokoll, „Gespräch behalten, Tage ohne neue Frage", ab Werk 365, erlaubt von 30 bis 3650, und unter ihm, wie viele Gespräche aller Konten die Frist heute löschen würde. Vorschau, Grenzen, Grund, „Speichern", „Verwerfen" und die Herkunft verhalten sich wie beim Schreibprotokoll; beide Karten teilen sich Fristtafel.tsx. Die Frist zählt ab der jüngsten Runde eines Gesprächs; es geht mit Frage, Antwort, Gegenstand und Herkunftszeichen jeder Runde. Geräumt wird vom selben Zeitgeber denotato-schreibprotokollraeumung; die sieben Tage für Absätze und Anstöße stehen fest in der Datenbank, weil nach ihrem Tag kein Code sie mehr liest.

Darunter steht die Karte „Von selbst melden" (KI29, N397). Sie sagt in einem Satz, wann die Eule sich von selbst meldet, dass eine Regel mit diesen Schwellen prüft, ob es so weit ist, dass das Modell den Satz erst beim Öffnen schreibt und dass jedes Konto jeden Anlass für sich abschalten kann. Darunter stehen fünf Felder: „Frist naht, Tage vorher" (ab Werk 3, erlaubt 1 bis 30), „Tage ohne Karten" (ab Werk 3, 1 bis 30), „Lücke im Stoff, Tage vor der Prüfung" (ab Werk 14, 1 bis 90) und seit dem 30.09.2026 (KI32, N421) „Wiedervorlage liegt, Tage überfällig" (ab Werk 1, 1 bis 30), seit dem 14.10.2026 (KN-261014-erststart-begleiter) „Erststart offen, Tage nach dem Anlegen" (ab Werk 3, 1 bis 30). Unter jedem Feld steht, was die Schwelle heute beim eigenen Konto träfe — „Heute träfe das eine Frist.", „… 3 fällige Karten.", „… 2 Prüfungen.", „… eine Wiedervorlage.", „… eine offene Frage des Erststarts." oder „Heute meldete sie sich dafür nicht." —, und darunter „Die Vorschau rechnet mit deinem Konto.": Die Anlässe anderer Konten liest die Verwaltung nicht. Tippt man eine andere Zahl, rechnet die Vorschau nach, sobald das Tippen ruht. Eine Zahl außerhalb der Grenzen nennt die Grenzen und sperrt „Speichern". Darunter stehen, wie beim Schreibprotokoll, wer die Schwellen wann aus welchem Grund gesetzt hat (oder „Werte ab Werk"), ein Feld für den Grund, „Speichern" und „Verwerfen". Die Schwellen liegen in admin.begleiter_werte (Wanderung 192; die vierte seit Migration 197, die fünfte seit Migration 323).

Die zweiundzwanzig Instanzwerte stehen nur lesend darunter: die fünf des Modells — Preise hin und zurück, Kurs, Monatsdeckel und seit KI89 die „Ausgaberate für den Preis eines Stopps“ (ab Werk 200 Token je Sekunde, 1 bis 10 000), nach der ein Stopp ohne gemeldete Nutzung geschätzt verbucht wird; seit KI-261006 nur noch der Rückfall, solange das Protokoll über alle Konten für das Modell weniger als 20 vollständige Rufe der letzten 30 Tage kennt (KI-261006-ausgaberate-alle) oder sich nicht lesen lässt, sonst gilt die daraus gelernte Rate, geklemmt auf dieselben Grenzen (Regel in begleiter.md) —, die acht Preise der Leiter, je Modell hin und zurück in US-Cent je Million Token, und seit KI38 die zwei Zeitgrenzen: „Leerlaufgrenze eines Modellrufs“ (ab Werk 30 Sekunden) und „Frist einer Anfrage an den Begleiter“ (ab Werk 240 Sekunden, höchstens 240), und seit KI-261007 die sechs des Zwischenspeichers: der Tarif in Promille des Preises hin — „Zwischenspeicher schreiben, fünf Minuten“ (ab Werk 1250), „…, eine Stunde“ (2000), „Zwischenspeicher lesen“ (100) und eigens für Opus 5.5 (50) und Fable 5.1 (25) — und die „Frist des Zwischenspeichers“ (ab Werk 5 Minuten; 60 bestellt beim Anbieter die Stunde), und seit KI-261013-naechtlicher-tagessatz der „Preis im Batch“ in Promille des regulären Preises (ab Werk 500, 1 bis 1000), zu dem der Satz zum Tag abgerechnet wird, der nachts als Message Batch hinausgeht. Gestellt werden sie unter Instanzwerte (N508); ein Satz unter der Liste verweist dorthin. Unter jedem Namen steht seit KI44, wann, von wem und warum der Wert in admin.instance_values gesetzt wurde („gesetzt am 03.10.2026, 20:56 von Christian · Grund: …“), oder „ab Werk“, wenn er nie gesetzt wurde; kommt er aus der Umgebung des Servers, steht nichts darunter. Gerade beim Kurs sieht man so, wie alt er ist. Das Protokoll am Ende lässt sich nach Konto, Anlass, Modell, Ausgang, Grund und Zeitraum filtern und seitenweise lesen; der Ruf des Vorab-Agenten heißt dort in der Spalte „Anlass" „Vorab-Agent". Jede Runde zum Nachlesen steht als eigene Zeile „Nachlesen" darunter (KI14). Es enthält nur Kenndaten wie Token, Kosten, Zeichenzahlen und Dauer, nie Frage, Antwort oder Gegenstand (B22, N240, N315). Seit KI-261007 (Wanderung 261) steht neben „Token hin / zurück“ die Spalte „Zwischenspeicher gelesen / geschrieben“: „Token hin“ ist nur noch die frisch gelesene Eingabe, die beiden anderen Teile kosten nach dem Tarif oben; Zeilen von vor der Wanderung zeigen „0 / 0“. Hat eine Zeile Kosten, aber weder Token hin noch Token des Zwischenspeichers, steht hinter dem Betrag „· nicht gemessen“ (KI89): Das ist der Vorbehalt einer offenen Zeile, der ganze Vorbehalt nach Leerlauf oder Frist oder die Schätzung eines Stopps, bevor der Dienst Verbrauch gemeldet hat.

Je Antwort zusammengefasst (KI-261007-kosten-je-nachricht, Wanderung 259). Jeder Aufruf trägt die Kennung der Antwort, zu der er gehört: Vorab-Agent, erster Ruf und jede Werkzeugrunde einer Frage teilen sie. Die Tafel fasst die Zeilen einer Antwort unter eine Summenreihe „Mi., 07.10., 21:41 · Blick · 0,04 $ · 3 Aufrufe · Sonnet 5.5 u. a.“ — Zeit und Konto der jüngsten Zeile, die Kosten aller Aufrufe der Antwort in Dollar (ab einem Cent zwei Stellen, darunter vier), ihre Zahl und das teuerste Modell, bei mehreren mit „u. a.“; steht noch eine Zeile offen, folgt „noch offen“. Die Reihe klappt auf und zu und zeigt dann die Einzelzeilen eingerückt; am Telefon ist sie so hoch wie die Zielfläche (44 px). Gezählt wird über alle Zeilen der Antwort, auch über die Seite hinaus. Zeilen ohne Kennung — alles von vor Wanderung 259 und Anlässe außerhalb einer Antwort — stehen wie bisher einzeln.

Die Spalte „Grund" (KI39, N501, Wanderung 227) sagt, warum ein Ruf so ausging, immer als feste Kennung und nie als Text aus Frage oder Antwort. Bei „am Deckel" ist es die Sperre: „Monatsdeckel der Instanz", „Monatsbetrag der Stufe", „Tagesdeckel", „Frage zu lang", „Bilder", „PDFs" oder „Kontext zu lang". Bei „nicht erreicht" ist es der Ausfall: „keine Verbindung", „Leerlauf", „Frist abgelaufen", „Strom gestört" oder der Statuscode des Anbieters, etwa „Status 529". Bei einer gekürzten oder verweigerten Antwort ist es der Haltgrund: „Tokengrenze erreicht", „Kontextfenster voll", „verweigert" oder „über der Zeichengrenze" (der Text war länger als die Zeichengrenze des Anlasses und wurde gekürzt — nur bei Text, Hinweis und Abschrift; JSON-Antworten und die Vorab-Wahl werden ganz gelesen und tragen diesen Grund nie). Eine vollständige Antwort hat keinen Grund und zeigt „—", ebenso jede Zeile von vor Wanderung 227. Zwischen den Filtern und der Tabelle steht je Grund, der unter dem übrigen Filter vorkommt, ein Knopf mit seiner Zahl („Tagesdeckel · 4"), der häufigste zuerst; gezählt wird über alle Seiten, nicht nur über die gezeigte. Ein Druck darauf setzt den Filter „Grund", ein zweiter hebt ihn auf. Der Filter bietet alle festen Gründe an und dazu jeden Statuscode, der gezählt wurde.

Alle zwölf Routen verlangen settings.global_default und antworten sonst mit 404 (darfVerwalten in begleiter/server/verwaltungsrouten.ts). BEGLEITER_MODELL liefert Ring, Vorgabe, Stufen samt Schätzung und Grundlage, Modellwahl, Protokollfrist, Verlaufsfrist, Anstoßschwellen, Denkraum und Instanzwerte. BEGLEITER_KONTINGENT, BEGLEITER_MODELLWAHL, BEGLEITER_PROTOKOLLFRIST, BEGLEITER_VERLAUFSFRIST, BEGLEITER_ANSTOSSSCHWELLEN und BEGLEITER_DENKRAUM schreiben ausschließlich über diesen Schirm und antworten mit derselben Übersicht; ein unbekanntes Modell, ein unbekannter Aufwand oder ein Aufwand beim Vorab-Agenten oder beim Mindestmodell mit Werkzeugen wird mit modellwahl-ungueltig abgewiesen; Fristen, Schwellen und Denkraum prüft schon das Schema der Route gegen ihre Grenzen, die Setzer prüfen sie noch einmal. BEGLEITER_PROTOKOLLFRIST_VORSCHAU, BEGLEITER_VERLAUFSFRIST_VORSCHAU, BEGLEITER_ANSTOSSSCHWELLEN_VORSCHAU und BEGLEITER_DENKRAUM_VORSCHAU rechnen die Vorschau für Werte, die noch nicht gesetzt sind, und schreiben nichts; BEGLEITER_PROTOKOLL liest das Protokoll. Die MCP-Werkzeuge begleiter_modell und begleiter_protokoll lesen nur (N295). Wanderung 145 stellt dafür die abgesicherten Funktionen personal.model_calls_protocol und personal.model_call_rates bereit, Wanderung 164 die Tabelle admin.modellwahl mit ihren fünf Zeilen ab Werk, Wanderung 188 die Zeile protokollfrist in admin.begleiter_werte und die beiden Funktionen personal.begleiter_changes_faellig und personal.begleiter_changes_raeumen, die nur eine Zahl herausgeben, Wanderung 192 die drei ersten Anstoßschwellen, 197 die vierte und 201 die fünf Werte des Denkraums in derselben Tabelle. Wanderung 227 gibt personal.model_calls die Spalte reason mit einem CHECK auf die festen Gründe und status_NNN, ersetzt personal.model_calls_protocol durch eine Fassung, die den Grund herausgibt und nach ihm filtert, und stellt personal.model_call_reasons bereit, die je Ausgang und Grund nur eine Zahl herausgibt. Wanderung 229 legt die Zeile verlaufsfrist mit ihren Grenzen an und stellt personal.begleiter_turns_faellig, personal.begleiter_turns_raeumen, personal.begleiter_briefings_raeumen und personal.begleiter_anstoesse_raeumen bereit, die ebenfalls nur eine Zahl herausgeben (KI47). Wanderung 261 gibt personal.model_calls die Spalten tokens_cache_read und tokens_cache_written und stellt personal.model_call_cache bereit, die je Kennung einer gezeigten Zeile nur diese beiden Zahlen herausgibt (KI-261007).

Unter „Vorhaben" steht über allem eine Reihe Zahlen, und jede ist ein Verweis (ES-261009-kennzahlen-nur, 10.10.2026): fertig · in Arbeit · blockiert · offen · bei euch · Ideen · insgesamt. Jede führt zu genau der Menge, die sie zählt: „9 blockiert" setzt Sicht Alle und Filter Zustand: blockiert, leert Suche und Bereichswahl, wechselt aus Leitstand, Bereichen oder Baum in die Kacheln (Kacheln und Tafel bleiben, was sie sind) und rollt zur Sichtleiste. „bei euch" und „Ideen" setzen die gleichnamige Sicht, „insgesamt" die Sicht Alle. Solange nichts gelesen ist, steht ein Strich statt einer Zahl, und die Knöpfe sind gesperrt: Sie führten in eine Liste, die es noch nicht gibt.

Jede Zahl trägt ihr Zeichen (N132, 22.09.2026): die vier Zustände den Zustandsring in seiner Zustandsfarbe (fertig grün, in Arbeit blau, blockiert rot, offen neutral), „bei euch" die Person, „Ideen" die Glühbirne, „insgesamt" das Klemmbrett. Das Wort bleibt daneben stehen; das Zeichen ist, woran das Auge die Zahl findet, bevor es liest. „blockiert" bleibt die dritte Zahl und steht rot, sobald es mehr als null sind — eine rote Lage gehört in den ersten Blick (N128).

Am Telefon rollt die Reihe (N190, 23.09.2026), statt in drei Zeilen umzubrechen, mit demselben dünnen Balken wie die Reiterleiste; wo sie weitergeht, blendet sie 32 px weit aus wie die Reiterreihe (E17, F69, useRollrand, theme/rollrand.ts). Innenabstand und ein gleich großer negativer Rand halten den Fokusring innerhalb der Rollfläche.

Was ging, und warum (E13). Bis zum 10.10.2026 stand die Reihe in einem gerahmten Band in zwei Reihen (seit dem 22.09.2026), und dazu gehörten vier Dinge ohne Handlung: die Zahl „gesperrt" (offen, aber der Bereich steht auf „Später" oder „Lass das"), die als einzige nirgendwohin führte, weil keine Sicht und kein Filter genau diese Menge trifft; der Gesamtbalken „83 % · 814/1028"; die Verlaufslinie von „erledigt" über neunzig Tage mit „+11 diese Woche" (W11; am Telefon schon seit dem 22.09.2026 weg); und der Aufklapper „Wie gezählt wird", der nur den Balken und „gesperrt" erklärte. Alle vier sind entfernt, Verlaufslinie.tsx mit ihnen. Der Server liefert Zählung und Verlauf weiter (stand.verlauf), und der Balken je Bahn und je Bereich bleibt, wo er neben einer Handlung steht.

Unter „System" steht die Reihe nicht (seit 22.09.2026): Dort stand dieselbe Zählung der Vorgänge über einer Tafel, die vom Bauzustand spricht.

Zwei Abschnitte statt fünf (20.09.2026)

Darunter standen zwei Reiter: Vorhaben (mit dem Klemmbrett) und System (mit dem Server) — seit N132 als Abschnitte mit Zeichen, wie der Rahmen sie erlaubt (00-rahmen.md, §3). Seit A41 sind es die ersten beiden Einträge der Spalte links.

Bis zum Abend des 20.09.2026 waren es fünf — Bei dir · Ideen · Läuft · Alles · System —, und drei davon waren Eimer mit Löchern. „Bei dir" nahm nur, was offen ist und bei Christian liegt; „Ideen" nur, was ich vorgeschlagen habe und noch kein Urteil hat; „Läuft" nur die angefangenen Zustände. Sechsunddreißig Vorgänge fielen durch alle drei — offen, aber bei mir, oder von Ben, oder aus Christians eigener Liste. Sie standen nur im Baum, und den ruft niemand auf, der eine Frage hat.

Christian hat den Befund geliefert: „Es fehlen viele Sachen einfach wie bspw. der Icloud-Kalender-Plan." Das Beispiel war richtig und die Diagnose eine andere als erwartet — BE10 gibt es seit dem 17.09.2026, dringlichkeit: hoch. Er war nur in keiner der Listen zu sehen.

Seine Entscheidung: Abschnitte weg, Filter hin. „Vorhaben" trägt seither eine Liste über alles. Was die drei Eimer waren, sind jetzt Sichten darauf — ein Knopf, der einen Filter setzt, nicht ein Ort, der etwas weglässt. Der Unterschied ist, was passiert, wenn niemand etwas anklickt: Ein Abschnitt zeigt dann seinen Ausschnitt, ein Filter alles.

Christian heißt hier beim Namen (23.09.2026). Bis dahin sprach der Schirm ihn an: „bei dir" im Band, in der Sichtleiste und im Filter, „Chris" auf der Karte, „Warum es bei dir liegt", „C · Bei dir" und „W · Deine Wünsche" im Entwurfsfach. Seit Ben die Verwaltung ebenfalls sieht (N144), stimmte das Fürwort für ihn nicht mehr, denn die Punkte warten nicht auf ihn. Ben: „kannst du dich darum kümmern, dass ‚bei dir' Christian heißt?" Im Code heißt die Sicht weiter beidir; das ist ein innerer Name, und bestehender Code wird nicht umbenannt (Grundsatz 1). Claude heißt seit N182 ebenso beim Namen (23.09.2026): „bei Claude", auf der Karte „Claude" — vorher „bei mir" und „ich", und für Ben las sich „ich" auf einer Karte, als läge der Punkt bei ihm.

Die Sichtleiste steht über dem Filter und hat vier Knöpfe: Alle · Bei euch · Ideen · Läuft. Alle steht vorn und ist die Vorgabe — das ist der ganze Umbau in einer Zeile. Seit N132 trägt jeder Knopf ein Zeichen vor dem Wort: Klemmbrett, Person, Glühbirne, das Zeichen für „läuft" (Kreis mit Dreieck).

„Bei euch" nimmt die Liste des Servers (seit 22.09.2026): alles, was bei Christian oder Ben liegt und weder fertig noch verworfen ist. Vorher rechnete der Schirm selbst „offen und bei Christian" und kam auf 38, während das Band 47 zeigte — die Zahl im Band und die Liste, zu der sie jetzt führt, müssen dieselbe sein. Bis N256 (24.09.2026) hieß die Sicht „Bei Christian" und nahm nur, was bei Christian lag; seit beide Denotato führen (N219), zählt sie beide, und sie ist dieselbe Menge, die die Bahn 1-bei-euch sammelt (dort ohne die dauernden). Die leere Sicht sagt „Nichts wartet auf euch. Das ist der gute Fall."

Zwei der drei sind keine Feldfrage, und deshalb stehen sie neben dem Filter und nicht darin: „Ideen" heißt von mir vorgeschlagen und noch unbeurteilt, und das steht in keinem einzelnen Feld. Welche Vorgänge das sind, sagt der Server — er kennt die Quelle jeder Datei. Die Regel hier ein zweites Mal zu schreiben hieße, zwei Fassungen zu haben, von denen eine abweicht.

Die Filterleiste (20.09.2026)

Darunter vier Felder mit Knöpfen: Zustand · Dringlichkeit · Liegt bei · Bereich. Mehrere Werte in einem Feld sind ein ODER, mehrere Felder ein UND. An jedem Knopf steht, wie viele Vorgänge er übrig ließe — die Zahl sagt vorher, wohin er führt, statt den Leser auf eine leere Liste laufen zu lassen.

Die Leiste steht hinter einer Pille (N190, 23.09.2026). Offen stand sie über jeder Liste, am Telefon 283 px und damit mehr als ein Drittel des Fensters, bevor die erste Kachel kam. Christian hat „Filterleiste als Pille in der Sichtleiste" gewählt: Die Sichten sind der grobe Schnitt und stehen immer da, der Feldfilter ist der feine und kommt auf Wunsch. Am Ende der Sichtleiste steht die Pille Filter (aria-expanded), die die Leiste darunter öffnet; die Vorgabe ist zu. Am Rechner trägt sie einen Winkel, der sich beim Öffnen dreht, dann Trichter und Wort — der Winkel steht vorn wie bei den Textaufklappern und sagt, dass sie etwas aufklappt. Sie setzt sich von den Sichten ab (N204, E17, 27.09.2026): Vor ihr steht mehr Luft als zwischen „Alle" und „Läuft", und mitten darin ein feiner senkrechter Strich in der Kantenfarbe. Vorher hatte sie dieselbe Höhe, denselben Rand und denselben Abstand wie die Sichten und sah aus wie eine fünfte. Am Telefon steht nur der Trichter, das Wort im aria-label (Guide §17): So bleibt die Sichtleiste eine Zeile.

Was gewählt ist, verschwindet nicht mit der Leiste. Ist sie zu, steht jede Wahl als Pille neben den Sichten — mit ihrem Zeichen, ihrem Wort und einem Kreuz —, und der Klick nimmt sie zurück. Ein Sprung über „blockiert" im Band bleibt so sichtbar, ohne dass man die Leiste öffnet; sonst filterte etwas, das man nicht sieht. Offen stehen dieselben Werte in der Leiste und nicht noch einmal als Pille. Die Pillen der Sicht- und der Gliederungsleiste sind unter pointer: coarse so hoch wie die Zielfläche (44 px, vorher 25 px, Guide §16.1).

Vier Felder und nicht alle. Titel und Beschreibung beantwortet die Suche, Verweise und Schritte sind Listen. Was hier steht, sind die vier Fragen, die man an zweihundert Vorgänge wirklich hat: wie weit · wie dringend · bei wem · welcher Bereich.

Auf dem Knopf steht das Wort der Oberfläche, nicht der Wert aus der Datei: laeuft heißt hier „in Arbeit", claude heißt „bei Claude" — dieselben Wörter, die der Feldsteller nimmt. Ein Filter und ein gestellter Wert dürfen nicht verschieden klingen. Seit N132 gilt das auch für den Bereich: calendar heißt „Kalender", geplant:duell heißt „duell (geplant)". Die Zeichen je Wert (Ring, Rang, Person, Bereichsscheibe) gibt der Schirm der Leiste schon mit; gezeichnet werden sie erst, wenn die Leiste im Gerüst sie annimmt (siehe „Was fehlt").

Die Leiste selbst liegt im Gerüst (frontend/src/components/dataview/Filterleiste.tsx), der Filter als Handfilter in config/views/viewTypes.ts. Sie ist nicht für die Verwaltung gebaut, sondern für jede Liste, die Felder hat.

„Bereich" ist zugeklappt (seit 22.09.2026): vierzig Werte in fünf Zeilen standen über jeder Liste, und den Bereich wählt man meist von der Wand. Zugeklappt stehen die Überschrift, was gewählt ist — als Pille, die die Wahl zurücknimmt — und „40 Werte zeigen". Wie das Zuklappen funktioniert, steht im Rahmen (00-rahmen.md, §6).

Eine Wahl bleibt stehen, auch wenn nichts mehr darauf passt (Nachbesserung 22.09.2026). Seit die Zahlen auf der gesuchten Menge rechnen, fiel ein gewählter Wert ohne Treffer aus der Reihe: „9 blockiert" im Band gedrückt, dann „Mensa" gesucht — die Pille blockiert war weg, die Liste leer, und nirgends stand, warum. Bei einer Suche ohne jeden Treffer verschwand die ganze Leiste samt „alles zeigen". Jetzt steht die Wahl mit einer 0 da, gedrückt und mit ihrem Wort („in Arbeit", nicht laeuft), offen wie zugeklappt, und die Leiste bleibt, solange etwas gewählt ist.

Die Zahl am Knopf zählt, was man sieht. Sie rechnet seit dem 22.09.2026 auf der Menge nach Sicht, Bereichswahl und Suche — vorher nach Sicht allein. Mit „Bereich: Kalender" stand an „blockiert" eine 9, und ein Klick ergab zwei Kacheln. Die Wand-Pille ist dabei kein Eintrag der Filterleiste, sondern steht vorn in der Sichtleiste; sie wirkt aber auf die Zahlen wie einer.

Leitstand (B-261013-leitstand-ansicht)

Der Leitstand zeigt, was der Dienst auf dem CX33 je Konto tut, und nimmt die Befehle an ihn entgegen. Er wird beim Öffnen und danach jede Minute neu gelesen, solange die Seite sichtbar ist; beim Zurückkehren auf die Seite sofort. Ein Lesefehler steht als Meldung mit Nochmals lesen über dem letzten guten Stand, der stehen bleibt. Solange ein Befehl läuft, nimmt der Leitstand keinen zweiten an; der gedrückte Knopf dreht sich, alles andere bleibt, wie es ist, auch der Fokus. Danach wird einmal neu gelesen. Eine Erfolgsmeldung gibt es nicht — der neue Stand ist die Rückmeldung. Ein abgewiesener Befehl nennt seinen Grund in einem Satz. Beim ersten Lesen stehen graue Platzhalter in der Form der Felder.

Seit dem 14.10.2026 (KN-261014-leitstand-gestalten, Richtung A des Musterbogens docs/gestaltung/musterboegen/leitstand-ordnung.html) beantwortet der Schirm drei Fragen in dieser Reihenfolge: Läuft alles? (Lage: Kontoleiste und Pult als zwei Felder nebeneinander, solange Platz ist), Was braucht mich? (rechts daneben: Sitzungen, die fragen oder hängen, dann die offenen Fragen und der Eingang), Was arbeitet gerade? (darunter über die ganze Breite: Sitzungen, dann die Bahnen). Darunter stehen drei Reiter zum Nachschlagen: Verlauf (Kennzahlen, Wochenkurve, Verbrauch je Bahn; offen beim Öffnen), Steuern (Überschreibungen und Einstellungen) und Protokoll.

Die Felder ordnen sich nach der Breite, die der Leitstand selbst hat, nicht nach der des Fensters. Breit teilen sich Lage und „Was braucht mich?“ die erste Zeile; das Feld „Was braucht mich?“ ist so hoch wie die Lage (mindestens sechs Zeilen) und rollt in sich, damit eine lange Fragenliste die Sitzungen nicht nach unten schiebt. Am Telefon steht alles untereinander in der Folge Kontoleiste, „Was braucht mich?“ (höchstens drei Fünftel der Schirmhöhe, rollt in sich), Pult, Sitzungen, Bahnen, Reiter — das Pult ist lang und stünde sonst zwischen den ersten beiden Antworten. Die Reiter sind unter dem Daumen 44 px hoch. Hat der Dienst noch nie gemeldet, steht oben über die ganze Breite ein Satz, dass Konten, Sitzungen und Überschreibungen mit seiner ersten Meldung erscheinen; Lage und Sitzungen fehlen bis dahin.

Anzeigen, von oben nach unten:

• Kontoleiste: je Konto die Betriebsart (Aus · Trocken · Scharf, jede mit einem Satz, was der Dienst dann tut), Verbrauch der Woche und des Fensters (5 h) als Balken ohne Farbe, nahe dem Ziel im Warnton, an der Haltegrenze im Gefahrton, und der letzte Takt. Darunter, falls es zutrifft, ein Satz: der Dienst hat noch nie oder seit Minuten nicht gemeldet, die Freigabe der Maschine fehlt, Denotato war nicht erreichbar, oder seine Uhr weicht ab.
• Pult: je Konto die Regelstufe und Zielzahl, eine aktive Überschreibung mit Ablauf, die letzten Aktionen des Dienstes und die wartenden Startwünsche mit ihrem Alter („vor 12 Minuten“, die Uhrzeit im Hinweis), weil ein Wunsch nach einer Weile verfällt.
• Sitzungen, die dich brauchen · n (nur, wenn es welche gibt): jede Sitzung, die fragt oder auf Antwort wartet, mit Bahn, Vorgang und Zeit der Frage; darunter je eine Zeile, wie viele Sitzungen stumm und wie viele verschollen sind (die verschollenen zeigt „Beendete zeigen“ in den Sitzungen).
• Fragen aus den Bahnen · n (nur, wenn eine wartet): die Fragen, die Bahnsitzungen mit node betrieb/frage.mjs gestellt haben, älteste zuerst, mit Bahn, Vorgang, den letzten sechs Zeichen der Sitzung und der Zeit. Hat eine Frage einen Musterbogen, steht darunter Musterbogen ansehen (eine Datei unter docs/gestaltung/musterboegen/) oder Musterbogen bei Claude öffnen (ein Artifact, in einem neuen Reiter, weil claude.ai sich nicht einbetten lässt). Dann ein freiwilliges Feld Anmerkung zur Wahl und die Möglichkeiten als ganze Zeilen: die empfohlene zuerst, gerahmt in der Handlungsfarbe und mit dem Chip Empfehlung, der Preis klein darunter.
• Offene Fragen: Vorgänge, die bei Christian oder Ben liegen, mit ihrem Alter, Fragen aus Konzepten und der Eingang. „Eingang · n“ zählt alle wartenden Einfälle; die Liste zeigt die zehn neuesten. Darüber, nur wenn welche warten, „Rückmeldungen · n“: übernommene Rückmeldungen, die noch kein Vorgang in quelle: nennt (B-261013-rueckmeldung-freigeben), mit Art, Seite und Alter; hält schon ein Entwurf eine, steht „Entwurf <Kennung>“ dabei. Einen Knopf gibt es nicht: Für sie startet der Leitstand eine Sitzung in 6-fehler (2026-10-15-rueckmeldungen-ohne-klick).
• Sitzungen: je Sitzung Bahn, Vorgang, Zählung, Anweisung, Start und letzte Meldung; Beendete auf Wunsch. Sonst „Keine Sitzung läuft.“
• Bahnen: die frühere Bahnen-Sicht mit Zustand, Priorität, offenen Vorgängen, laufenden Sitzungen und gewünschten Starts. Im Kopf „… Sitzungen laufen · Regler erlaubt …“, sobald ein Konto gemeldet hat. Gezeigt werden die Bahnen, die laufen, warten, gebremst sind oder einen offenen Startwunsch haben, samt ihren Elternbahnen; die übrigen liegen unter Ruhende Bahnen · n zugeklappt. Eine laufende Bahn nennt die Kennung ihres Vorgangs; „… offen“ steht nur, wenn der Vorrat gelesen ist und etwas offen ist.
• Verlauf (Reiter Verlauf, über den Kennzahlen; B-261018-leitstand-verlauf): rechts neben der Überschrift die Zeitraumwahl 6 Stunden · 24 Stunden · 7 Tage · alles (Vorgabe 24 Stunden); der Reiter merkt sich die Wahl im Browser, beim Abmelden geht sie mit. Je Konto ein Feld „Sitzungen je Zählung, <Konto>“: die Sitzungen je Zählung als gestapelte Flächen in den Zustandstönen (von unten arbeitet, stumm, im Anlauf, wartet auf Antwort, fertig, verschollen), das Ziel als gestrichelte Stufenlinie auf derselben Achse, Woche in Prozent als Linie und Fenster in Prozent gepunktet auf der Prozentachse rechts; Linien ohne Farbe. Darunter Vorgänge über die Zeit: je Lauf ein Balken von Beginn bis Ende (bis jetzt, solange er läuft), gefärbt nach Ausgang (läuft, fertig, verschollen, gebremst, abgelöst), höchstens die vierzig jüngsten; der Hinweis am Balken nennt Vorgang, Ausgang und Dauer. Zuletzt Läufe als Tabelle mit Vorgang (Kennung, Titel, Bahn), Beginn, Dauer, Ausgang und Verbrauch in Punkten der Woche; am Telefon als Zeilenkarten. Die Daten faltet der Server aus jedem Takt in eigene Tabellen ohne Verfall (Wanderung 355); was vor dem ältesten noch gespeicherten Takt lag, kennt er nicht, und dann steht „Der Verlauf beginnt am …“ darunter. Ohne Takt: „Noch kein Takt im Verlauf.“ Alle fünf Minuten neu gelesen, solange die Seite sichtbar ist.
• Kennzahlen (Reiter Verlauf): vier Kacheln. Erledigt diese Woche mit der Änderung zur Vorwoche und den acht Wochen als Balkenreihe; Durchlaufzeit als Median in Tagen, dazu „9 von 10 unter … Tagen“ und aus wie vielen Vorgängen; Verbrauch je Vorgang als Mittel in Punkten der Woche („3,2 Pkt.“; der ausgeschriebene Satz „… Prozentpunkte der Woche“ steht im Hinweis, damit die Zahl nicht zweimal dasteht), darunter die drei größten als „Kennung · Punkte“; Offene Fragen mit Zahl und Alter der ältesten, „—“, solange der Stand des Leitstands fehlt. Ändert sich eine ganze Zahl, zählt sie zum neuen Wert. Die laufende Woche ist in der Balkenreihe dunkler, nicht farbig. Darunter die Wochenkurve je Konto gegen das Soll, so breit wie ihr Feld: Linien ohne Farbe, die Konten durch ihre Strichelung unterschieden, das Soll heller und gestrichelt, nur die Ziellinie im Warnton; Soll, Ziellinie, „jetzt“ und die Rücksetzzeit gelten für das erste gemessene Konto, und die Legende zeigt je Linie ein Stück von ihr und nennt nach Soll das Ziel („Ziel 85 %“). Zuletzt Verbrauch je Bahn · 24 h; solange nichts gemessen ist, sagt ein Satz, dass in den letzten 24 Stunden keine Bahn verbraucht hat. Die Balken wachsen mit der Feder auf ihren Wert. Alle fünf Minuten und nach jeder neuen Anmeldung neu gelesen, solange die Seite sichtbar ist. Scheitert das Lesen, steht an Stelle aller Kennzahlen, auch der Kurve und der Balken, ein Satz.
• Überschreibungen (Reiter Steuern): je Konto Starts pausieren, Ziel festsetzen und Alles halten, jede mit ihrem Zustand („nicht gesetzt“ oder „aktiv bis …“, beim festen Ziel mit der Zahl).
• Einstellungen (Reiter Steuern, zugeklappt, klappt mit der Feder auf): jede Einstellung mit Zweck, Vorgabe und wer sie gestellt hat. Seit B-261015-verschollene-belegungen steht dort auch Freigabe verwaister Belegungen (Vorgabe 360 Minuten): so lange ohne Commit, bis der Dienst den Anspruch einer toten Sitzung freigibt; jede Freigabe zeigt der Takt als Hinweis.
• Protokoll (Reiter Protokoll, zugeklappt): die letzten Zeilen des Dienstes, neueste zuerst, mit Zeit, Art, Konto, Bahn, Vorgang, Sitzung, Urheber, Grund und Einzelheiten. Am Telefon wird jede Zeile eine Karte.

Knöpfe:

Wege: /api/verwaltung/leitstand (VERWALTUNG_LEITSTAND) liefert den Stand, /api/verwaltung/leitstand/command (VERWALTUNG_LEITSTAND_COMMAND) nimmt einen Befehl, /api/verwaltung/leitstand/figures (VERWALTUNG_LEITSTAND_FIGURES) liefert die Kennzahlen. /api/verwaltung/leitstand/answer (VERWALTUNG_LEITSTAND_ANSWER) beantwortet eine offene Frage einer Bahnsitzung (laneQuestions im Stand, B-261013-leitstand-fragen); er hat kein MCP-Werkzeug, weil eine Bahnsitzung den Connector hält und sonst ihre eigene Frage beantworten könnte. /api/verwaltung/leitstand/sheet (VERWALTUNG_LEITSTAND_SHEET, Werkzeug verwaltung_musterbogen) liefert den Text eines Musterbogens aus dem ausgelieferten Baum, nur .html unter docs/gestaltung/musterboegen/, kein Weg hinaus, auch nicht über einen Verweis, höchstens 1,2 MB. Woher die Zahlen kommen, steht an jeder Stelle als Stempel: Zustand, Priorität und offene Vorgänge der Bahnen aus dem Vorrat (bash betrieb/bahn.sh naechste --alle auf beta, Stempel „Vorrat von …“); Erledigtes je Woche und Durchlaufzeit wie node betrieb/fluss.mjs aus Git auf beta (Stempel „Aus Git, Stand …“, die Herkunft im Hinweis); Titel und Fragen aus dem ausgelieferten Baum (Stempel „Titel und Fragen: Stand der letzten Auslieferung“, die Fassung im Hinweis).

Fünf Ansichten (W12/W14/W23)

Ein Reiter über der Liste: Leitstand · Bereiche · Kacheln · Tafel · Baum. Jede beantwortet eine andere Frage. Seit N132 steht vor jedem Wort ein Zeichen: die Übersicht, vier Kacheln, drei Spalten, das Sortieren, der Stamm mit zwei Ästen.

Bewegung (BW-261007-kacheln-uebersicht, Guide §11.2): In Kacheln, Tafel und Bereichs-Wand kommen und gehen Kacheln mit der Feder — wer filtert oder sucht, sieht gehende schrumpfen und die übrigen nachrücken. Die Bahnen im Leitstand klappen in der Höhe auf und zu, wenn sie dazukommen oder wegfallen, und die übrigen rücken nach. Die Zahl am Fortschrittsbalken zählt zum neuen Stand, Prozent und Erledigte (BW-261007-rueckmeldung). Bei der Bewegungsstufe „aus“ springt alles.

Der Leitstand steht seit dem 13.10.2026 vorn und ist die Vorgabe (B-261013-leitstand-ansicht). Er ersetzt die Bahnen-Sicht und trägt ihre Liste weiter; ?v=bahnen fällt auf ihn zurück. Davor standen die Bahnen seit dem 25.09.2026 vorn (N289). Die frühere Planbahn ist kein Reiter mehr: Sie ordnete Vorgänge von Hand, während die neue Bahnen-Sicht die parallele Arbeit aus dem Repository zeigt. Ihre Route und das MCP-Werkzeug bleiben für bestehende Aufrufer erhalten. Zuvor standen seit N127 die Bereiche vorn. Vorher (20.09.2026, „Bitte außerdem als Default Kacheln.") waren es die Kacheln, davor die Karten — also zwanzig Zeilen über den ersten Vorgang, bevor man weiß, wie viele es überhaupt sind.

Die Karten sind kein Reiter mehr, aber noch ein Ding. Die Karte ist das, was ein Klick auf Kachel, Tafelkarte oder Bahnzeile über der Ansicht öffnet — mit allem: Beschreibung, Verweise, Schritte, Urteile, Feldsteller, Kommentare. Ein Reiter, der das für zwanzig Vorgänge untereinanderstapelt, war die Übersicht, die keine ist. ?v=karten in einer alten Adresse fällt auf die Vorgabe zurück.

Der Baum war bis zum selben Abend ein eigener Abschnitt („Alles"). Er ist aber keine andere Menge, sondern eine andere Darstellung derselben — genau das, was ein Ansichtsreiter bedeutet. Als Abschnitt zwang er zu der Wahl „Liste oder Hierarchie", und wer die Hierarchie wollte, verlor dabei Suche und Filter. Als Ansicht hat er sie noch nicht: Er liest weiter den Baum, den der Server schickt (siehe „Was fehlt", Punkt 2). Deshalb stehen über ihm seit dem 22.09.2026 weder Suchfeld noch Sichtleiste noch Filterleiste — vorher standen sie da und bewirkten nichts: „blockiert" gewählt, 21 Zeilen vorher, 21 nachher. Was gewählt war, bleibt gewählt und steht in den Kacheln wieder da.

Nur der Baum bekommt die Gliederungsleiste — nach Ablage · nach Bahn · nach Bereich · nach Dringlichkeit · nach wem es liegt · nach Zustand. Dieselben Vorgänge, sechs Gliederungen. Eine flache Liste hat nichts zu gliedern; sie hat die Sicht und den Filter.

Nach Bereich folgt der Baum seit N132 der Wand: dieselben Kacheln in derselben Reihenfolge — also nach Priorität —, jede als Knoten mit dem Rang daneben, darunter ihre Themen als eigene Knoten (ebenfalls mit Rang, in ihrer Reihenfolge), und was kein Thema hat, hängt direkt am Bereich. Ein Thema ohne Vorgänge erscheint hier nicht. Vorgänge ohne Bereich stehen unter ihrer Gruppe, wie auf der Wand — vorher war das ein einziger Knoten „ohne Bereich".

Nach Bahn zeigt der Baum die Bahnen (N197, 23.09.2026): Gruppe → Gebiet → Bereich → Vorgang, so wie bash betrieb/bahn.sh stand sie aufzählt. Die Gebiete kommen aus docs/vorhaben/GEBIETE.md; ein Vorgang ohne Bereich hängt direkt am Gebiet rahmen, ein Gebiet ohne Vorgänge fehlt. Gruppen mit Unterordnern (4-grundlagen, 5-bereiche) teilen sich nach ihnen statt nach Gebiet — genau wie ihre Bahnen. Neben jedem Titel steht in Schreibmaschinenschrift der Name der Bahn (6-fehler-planung), den /bahn erwartet; der Hinweis beim Zeigen sagt Bahn wählen: /bahn 6-fehler-planung. 1-bei-euch und erledigt tragen keinen Namen: In erledigt gibt es keine Bahn, und die Bahn 1-bei-euch (N256) geht quer durch alle Gruppen — sie sammelt, was bei Christian oder Ben liegt, und passt an keinen Knoten des Baums. Die Gliederung heißt „nach Bahn“, obwohl der Reiter Bahn etwas anderes ist — die Reihe dessen, was als Nächstes kommt; Christian hat den Namen so gewählt, und der Hinweis am Namen trennt beides.

Am Telefon steht der Balken im Baum unter dem Namen (23.09.2026), eingerückt bis zum Anfang des Namens. Daneben bekam er 45 % der Zeile — weniger, als Gleis und Zahl zusammen brauchen, und „68 % · 66/113“ lief am rechten Rand aus dem Bild. Am Rechner bleibt er rechts neben dem Namen.

Die Tafel hat kein Ziehen und Fallenlassen. Ein Zustand ist eine Aussage über die Arbeit, keine Position; eine Karte, die beim Danebenfallen lautlos in den falschen Zustand rutscht, ist schlimmer als ein Klick mehr.

Der Balken hat drei Felder statt einer Zahl: voll für erledigt, schraffiert für laufend, leer für offen. „62 %" beantwortet nicht, ob die restlichen 38 % in Arbeit sind oder unberührt liegen.

In den Kacheln steht Erledigtes hinten (N199, 23.09.2026) — hinter allem Offenen, sonst in derselben Reihenfolge wie bisher. Die Reihenfolge fragte nach Anheften und Dringlichkeit, nicht nach dem Zustand, und achtzehn der zweiundzwanzig Vorgänge mit „sperrt" waren erledigt: Sie standen im ersten Blick vor jeder offenen Kachel. Verworfenes steht ebenso hinten; dauernd zählt als offen, denn eine Pflicht ohne Ende ist weiter zu tun.

Die Bereichs-Wand (W14, ab 22.09.2026)

Christian am 22.09.2026 (N127): „Eigenes Feld pro Bereich dass aber zuerst wirkt. Wenn ein Bereich als nicht machen markiert ist, wird vorerst unabhängig von den Einzeleinstellungen keins der Unter-To-Dos gemacht." Und zu den Vorgängen ohne Bereich: „Kacheln je Gruppe, zweite Reihe."

Abschnitte nach Gebiet, dann eine Reihe ohne Bereich. Oben die Bereiche — eine Kachel je Bereich, unter dem ein Vorgang liegt —, seit N197 (23.09.2026) in Abschnitten nach Gebiet: Planung · Lernen · Wissen · Leben · Konto · Austausch · Rahmen, in dieser Reihenfolge, aus docs/vorhaben/GEBIETE.md. Christian: „Die ca. 40 Bereiche sind immer noch viel zu viel und zu unübersichtlich." Jeder Abschnitt hat eine Überschrift mit dem Gebiet und daneben gedämpft, was darin liegt (4 Bereiche · 23 offen); ein Bereich, den die Datei nicht nennt, steht unter Rahmen. Innerhalb eines Abschnitts zuerst nach Priorität (seit N132: sperrt · hoch · mittel · niedrig · keine), innerhalb derselben Stufe wie bisher: gebaute zuerst, alphabetisch nach Titel, dann die geplanten (geplant:duell im Dateikopf) mit der Marke geplant. Die Reihenfolge rechnet der Server; der Schirm schneidet nur in Abschnitte. Vorher (22.09. bis 23.09.2026) stand oben eine einzige Reihe Bereiche — gebaute und geplante. Darunter Ohne Bereich — nach Gruppe der Ablage: eine Kachel je Ordner, in dem Vorgänge mit bereich: - liegen (Grundlagen · Betrieb, Bei euch, …), mit der Marke ohne Bereich, ebenfalls zuerst nach Priorität, dann in der Reihenfolge der Ablage. Die Priorität sortiert innerhalb eines Abschnitts; ein Bereich mit sperrt springt nicht in ein anderes Gebiet, eine Gruppe nicht nach oben. Ein Abschnitt, in dem nichts liegt, fehlt.

Gebaut heißt: im Register — mit Schirm oder ohne (F83, 24.09.2026). Ein Bereich ohne eigenen Schirm — timer, schlaf, auth und die übrigen Plugins mit route: null — steht wie jeder gebaute: mit dem Titel seiner Deklaration („Lern-Timer"), seiner Scheibe und seiner Lage, ohne die Marke geplant. Einen Link trägt er nicht, aber das tut keine Kachel; ihr Titel wählt den Bereich für die Liste darunter. Der Server baut die Wand dafür mit leseBereichslagen (alle Plugins), nicht mit der Liste des Reiters System, die nur die Bereiche mit Schirm führt. Bis zum 24.09.2026 stand ein Vorgang an timer deshalb als „timer (geplant)" auf der Wand.

Auf der Kachel stehen vorn die Bereichsscheibe — das Zeichen des Bereichs in seiner Farbe (N132; eine Gruppe der Ablage trägt das Zeichen ihrer Art, ein geplanter Bereich die Raute, beide neutral, weil sie keine Farbe haben) — und daneben der Titel als Knopf; darüber der Rang der Priorität (derselbe Winkel wie am Vorgang; bei niedrig ein blasser Winkel nach unten, bei keiner nichts), der Schlüssel (calendar, gruppe:4-grundlagen/betrieb), die Lage — dieselbe Rechnung wie in der Systemtafel, auch für einen Bereich ohne Schirm —, falls sie nicht an ist (ausgeschaltet, nicht gewährt), der Balken über alle Vorgänge darunter, die Zahl der offenen (7 offen, mit Themen 7 offen · 2 Themen), die drei Knöpfe Bau das · Später · Lass das — dieselben Worte wie an der Vorgangskarte — und darunter der Prioritätsknopf (siehe „Priorität und Themen"). Der gewählte Knopf ist umrandet und gedrückt; ein zweiter Klick darauf nimmt das Urteil zurück. Eine vierte Stellung „kein Urteil" als eigener Knopf wäre ein Wort für das Fehlen von etwas. Das Urteil zeigt der gedrückte Knopf; den Streifen links in der Farbe des Urteils gibt es seit dem 10.10.2026 nicht mehr (ES-261009-farbige-seitenstreifen, E11).

Das Urteil am Bereich wirkt zuerst. Später oder Lass das am Bereich sperrt jeden Vorgang darunter, was auch immer an ihm selbst steht; Bau das am Bereich hebt kein Lass das am Vorgang auf, dann gilt das eigene. Die Regel steht genau einmal, in @shared/types/verwaltung.ts (sperrtBereich), und verify:verwaltung nimmt sie beim Wort. Gesperrte Vorgänge bleiben in Kacheln, Tafel, Bahn und Baum — gedämpft, mit der Marke Bereich: Lass das bzw. Bereich: Später auf Kachel und Karte, damit das Zeichen ein Wort hat. Bis zum 10.10.2026 zählte im Band eine eigene Zahl gesperrt — offen, aber vom Bereich angehalten; sie führte nirgendwohin und ist entfernt (ES-261009-kennzahlen-nur). Die gedämpften Kacheln sagen es weiter.

Ein Klick auf den Titel wechselt zu den Kacheln, gefiltert auf den Bereich, und rollt zur Sichtleiste (seit 22.09.2026 — vorher stand der Blick danach mitten in der Kachelliste, und man sah nicht, dass ein Filter gesetzt war). In der Sichtleiste steht dann eine Pille mit der Scheibe des Bereichs, Bereich: Kalender und dem Schließen-Zeichen, und ein Klick darauf nimmt die Wahl zurück. Die Wand selbst zeigt keine Vorgänge — sonst wäre sie der Baum mit anderer Gliederung — und hört weder Sicht noch Filter noch Suche: Sie fragt nach dem Bereich, nicht nach dem Vorgang. Deshalb stehen über ihr auch kein Suchfeld, keine Sichtleiste und keine Filterleiste.

Wo das Urteil liegt. In admin.bereichsurteile (Migration 89), je Mensch und Schlüssel eine Zeile; „kein Urteil" ist eine gelöschte Zeile, keine dritte Spalte. Der Schlüssel ist die Plugin-Kennung ohne geplant:-Präfix — damit das Urteil den Tag überlebt, an dem der Bereich gebaut wird — oder gruppe:<ordner>. Gerechnet werden die Kacheln auf dem Server (admin/server/bereichswand.ts), mit der Zusicherung, dass jeder Vorgang unter genau einer Kachel liegt; der Schirm zeigt sie nur. Endpunkt: POST /api/verwaltung/bereichsurteil (VERWALTUNG_BEREICHSURTEIL), MCP: verwaltung_bereichsurteil; die Werkzeugantwort von verwaltung_offen trägt die Bereichsurteile unter bereiche mit, damit die Nacht sie als Sperrkorn liest, bevor sie einen Vorgang anfängt.

Vor Migration 89 gibt es die Tabelle nicht. Der Leser fragt vorher mit to_regclass nach und liest dann eine leere Karte — die Wand steht da wie bei jemandem, der noch keinen Bereich beurteilt hat. Bis zum 22.09.2026 (nachts) warf er stattdessen, und weil der ganze Verwaltungsstand in einer Transaktion gelesen wird, blieb /admin leer. Ein Druck auf einen Urteilsknopf antwortet bis dahin mit „den gibt es hier nicht" (FEATURE_NOT_AVAILABLE), nicht mit einem Serverfehler. Geprüft in verify:verwaltung, Punkt 13.

Priorität und Themen (N132, ab 22.09.2026)

Christian am 22.09.2026 (N132): Die Bereiche der Wand sind die Kategorien. Jede trägt eine Priorität — dieselben vier Stufen wie ein Vorgang, derselbe Rang-Winkel —, und die Wand sortiert danach. Unter einem Bereich stehen Themen (Unterkategorien), die man anlegen, benennen, priorisieren und zuordnen kann; sie tragen dieselben Stufen.

Die Priorität eines Bereichs stellt der Knopf unter den Urteilsknöpfen. Zugeklappt zeigt er, was gilt — Rang und Wort, oder Priorität, wenn nichts gesetzt ist —, ein Klick klappt die Reihe sperrt · hoch · mittel · niedrig auf (dazu keine, wenn etwas gesetzt ist). Die gewählte Stufe nimmt sich beim zweiten Druck zurück, wie ein Urteil. Zwei Klicks bis zur Änderung, keiner bis zur Auskunft; vier Rangknöpfe dauerhaft neben drei Urteilsknöpfen hätten die Kachel zum Formular gemacht. Danach liest der Schirm neu, und die Wand steht in der neuen Reihenfolge.

Die Bereichsansicht — nach einem Klick auf einen Kacheltitel, in den Kacheln — ist nach Thema gegliedert: oben ein Feld Neues Thema mit Anlegen (auch mit der Eingabetaste), darunter je Thema eine Überschrift mit Namen, n offen (über den ganzen Bereich, nicht nur über das, was Filter und Suche zeigen), dem Prioritätsknopf, einem Stift zum Umbenennen (Eingabetaste oder Sichern, Escape bricht ab) und einem Papierkorb zum Entfernen — und darunter die Kacheln des Themas. Die Themen stehen nach Priorität, dann nach Namen; Ohne Thema steht zuletzt und nur, wenn dort etwas liegt. Ein Thema ohne Vorgänge sagt leer, eines, dessen Vorgänge der Filter ausblendet, nichts passt zum Filter. Hat der Bereich kein Thema, steht nur das Anlegefeld über den Kacheln. Scheitert Anlegen oder Umbenennen, bleibt der getippte Name im Feld stehen, und oben steht die Meldung. Tafel und Bahn bleiben ungegliedert: Ihre Ordnung ist schon die Aussage.

Entfernen geht bei einem leeren Thema mit einem Klick. Trägt es Vorgänge, wird der Knopf zu n lösen?, daneben ein Kreuz zum Abbrechen; erst der zweite Druck entfernt es und stellt jeden Vorgang darunter auf ohne Thema.

Zugeordnet wird am Vorgang: In der Bereichsansicht trägt der Feldsteller jeder Kachel eine vierte Zeile Thema — eine Auswahl ohne Thema plus die Themen des Bereichs. Hier eine Auswahl statt Knöpfen, weil die Zahl der Themen offen ist, anders als die der Zustände. Der Weg ist derselbe wie für jedes Feld (stellen, Feld thema), mit dem Punkt „steht noch in keiner Datei".

Wo was liegt — und warum zwei Hälften. Die Zuordnung steht in der Datei: das Kopffeld thema: abo (klein, ohne Leerzeichen, ein Wert; - für keines), geprüft von verify:vorhaben (Regel 18). Name und Priorität stehen in der Datenbank (admin.bereichsthemen, Migration 91, je Mensch, Bereich und Kennung eine Zeile). So bleibt das Repository die Quelle der Zuordnung, und Umbenennen fasst keine Datei an. Die Kennung entsteht beim Anlegen aus dem Namen (Abo und Kündigung → abo-und-kuendigung). Ein Thema, das nur in einem Dateikopf steht, ist trotzdem eines: Es heißt wie seine Kennung und hat keine Priorität, bis jemand ihm eine gibt. Die Priorität der Bereiche steht in admin.bereichsprioritaeten (Migration 91) — eine eigene Tabelle und keine Spalte an admin.bereichsurteile, weil eine Zeile dort heißt „es gibt ein Urteil" und „kein Urteil" eine gelöschte Zeile ist.

Beim Entfernen löst der Server die Zuordnungen über die Änderungsschicht, in derselben Transaktion: Nennt die Datei das Thema, entsteht ein Auftrag thema: -; stand es nur in Denotato, fällt die Überlagerung weg. Sonst stünde das Thema nach dem Entfernen sofort wieder da, weil die Dateien es noch nennen.

Vor Migration 91 fehlen beide Tabellen. Der Leser fragt mit to_regclass und liest leere Kategorien; die Wand steht dann da wie bei jemandem, der noch nichts eingeordnet hat. Ein Druck auf einen Prioritäts- oder Themenknopf antwortet mit „den gibt es hier nicht" (FEATURE_NOT_AVAILABLE). Geprüft in verify:verwaltung, Punkte 14–20.

Projekte und ihre Teile (W12, ab 20.09.2026)

Ein Vorgang kann Teil eines Projekts sein. Im Kopf der Vorgangsdatei steht dafür ein Feld eltern: mit der Kennung des Projekts; die Gegenrichtung (kinder) rechnet der Leser aus, sie steht nirgends doppelt.

Höchstens zwei Ebenen. Ein Teil eines Teils ist keine Gliederung mehr, sondern eine Ablage — und eine Ablage hat diese Ablage schon: Gruppe, Untergruppe, Bereich. verify:vorhaben hält beides fest: dass jedes eltern: auf einen Vorgang zeigt, den es gibt, dass kein Kreis entsteht, und dass ein Kind nicht selbst Kinder hat.

Der Ordner ist die Ablage, eltern: ist die Sache. Am 20.09.2026 lagen vier von vierzehn Teilen in einem anderen Ordner als ihr Projekt, und das ist der Fall, für den die Trennung gebaut ist. BE14 liegt sogar in erledigt/ und trägt sein eltern: trotzdem — sonst zählte der Balken eines Projekts nur die offenen Teile und stünde auf null.

Ein Projekt trägt zwei Stände nebeneinander, und beide stimmen: seinen eigenen zustand: als Ring, und den Stand seiner Teile als Balken (anteilVon, fortschrittDerTeile in server/vorhabenlesen.ts). Ein Projekt, dessen vier Teile halb fertig sind, steht mit seinem eigenen Zustand unter „offen" und trägt trotzdem einen halben Balken. Nur beides zusammen beantwortet „wie weit ist das?".

Warum es die Ordnungen nicht getan haben

Auf Christians Wunsch nach „mehr Kategorien/Hierarchie" stand am Nachmittag des 20.09.2026 eine andere Antwort hier: fünf Ordnungen statt einer tieferen Hierarchie — der Baum sei schon drei Ebenen tief und trotzdem nur eine Gliederung, also brauche es nicht eine vierte Ebene, sondern fünf Sortierungen.

Christian hat diese Antwort verworfen: „Es gibt noch viel zu wenige kleine Unterpunkte und gar keine hierarchischen Projekte und Programmteile wie gefordert."

Er hatte recht, und der Fehler war nicht die Zahl der Ordnungen. Fünf Sortierungen ordnen gleichrangige Dinge, und genau das war der Befund: W08 heißt „Verbindungen statt API-Schlüssel — V1–V9" und zählte seine neun Teile als Fließtext auf, während dieselben Teile daneben als eigene Dateien lagen. Eine Datei gegen einen Absatz, zwei Kopien derselben Sache. Dasselbe bei NB08. In der Ablage waren ein Projekt und sein Teil dasselbe Ding, und keine Sortierung repariert das — sie stellt die Kopien nur schöner nebeneinander.

Die Ordnungen sind nicht weg; sie sind dort, wo sie hingehören: als Gliederungsleiste über dem Baum. Was dazugekommen ist, ist die Kante, die ihnen gefehlt hat.

Projekt-Kacheln statt einer Liste von allem (20.09.2026)

Christian: „ich will, dass die Verwaltung viel ausgereifter ist mit Projekt-Kacheln statt einer Liste von allem."

Die Kachelansicht warf bis dahin zweihundertacht gleichrangige Kacheln ins Raster. Ein Projekt sah darin aus wie einer seiner Teile, und beide standen nebeneinander — die Gliederung, die es seit demselben Abend in den Dateien gibt, kam in der Hauptansicht nicht an.

Eine Projektkachel ist deshalb etwas anderes als eine Kachel:

Gebündelt wird erst am Ende — nach Sicht, Filter und Suche, und nur dann, wenn das Projekt selbst noch in der Liste steht. Wer nach „blockiert" filtert, bekommt die blockierten Teile als eigene Kacheln und nicht die Projekte, in denen sie hängen. Sonst zeigte ein Filter etwas anderes, als er sagt.

Die Teilzeilen stehen dafür vollzählig da, auch wenn ein Filter sie aus der Liste genommen hat: Ein Projekt, das drei von acht Teilen zeigt, behauptet etwas über das Projekt, was nicht stimmt. Der Filter entscheidet nur, welche Zeilen sich stellen lassen. Ab dem siebten Teil klappt die Liste zusammen — beim größten Projekt im Bestand (NB08, acht Teile) ist der Deckel die Ausnahme und nicht die Regel.

Ein Vorgang ohne Kinder bleibt eine gewöhnliche Kachel. Welche Form wofür gilt, entscheidet nicht der Aufrufer, sondern kachelstuecke — sonst stünde ein Teil eines Tages zweimal auf dem Schirm.

Die Suche (20.09.2026)

Bis zum Abend waren es drei includes auf Titel, Kennung und „worum es geht", und die Antwort darauf war ja oder nein. Bei 228 Vorgängen ist beides zu wenig: Wer „kalender" tippt, bekommt vierzig Treffer in der Reihenfolge der Ablage, und wer „prufung" tippt, bekommt keinen.

Was sich geändert hat, und das Zweite ist das Wichtigere:

Mehr Felder. Ein Vorgang ist nicht sein Titel. Bereich, Zuständigkeit, Gruppe, „fertig, wenn", die Titel dessen, worauf er zeigt, und seine Schritte gehören dazu — sonst muss man raten, wie die Datei heißt, statt zu wissen, worum es geht.

Rangfolge statt ja/nein. Ein Treffer in der Kennung steht vor einem im Titel, der vor einem im Text. Eine Liste, in der ein Treffer in der Kennung hinter einem Nebensatz in einer Beschreibung steht, lässt den Leser die Arbeit tun, die die Suche hätte tun sollen. Wer die Kennung ganz tippt, meint diesen einen Vorgang: C01 steht dann oben und nicht hinter dem, der „C01" in sechs Feldern beiläufig erwähnt.

Dazu: Umlaute sind egal (prufung findet Prüfung), mehrere Wörter sind ein UND und müssen nicht nebeneinander stehen, und feld:wert sucht in einem Feld — bereich:calendar, zustand:blockiert, liegt:christian, eltern:W08. zustand: versteht beides, die Kennung und das Wort auf der Marke: Wer die Oberfläche liest, kennt nur das eine, wer die Datei liest, nur das andere.

Was es nicht gibt, ist eine unscharfe Suche über Tippfehler hinaus. Levenshtein auf 228 kurzen Titeln findet bei Abstand 1 schon mehr Falsches als Richtiges — „C01" und „C11" sind zwei Vorgänge und nicht zwei Schreibweisen desselben.

Die Suche wirkt in Kacheln und Tafel — und das Suchfeld steht seit dem 22.09.2026 auch nur dort (bis N289 auch in der Bahn). Unter Leitstand, Bereiche, Baum und System fehlt es: Ein Feld, das nichts filtert, ist ein Versprechen, das der Schirm nicht hält (Rahmen, §3). Wer von der Wand aus suchen will, wechselt vorher zu den Kacheln.

Auf der Tafel fallen dabei Spalten weg, in denen nichts mehr liegt. Hier stand bis zum 22.09.2026, die Spalten blieben stehen und die Suche filtere nur die Karten in ihnen — so stand es auch im Code-Kommentar, getan hat der Code es nie (siehe „Was fehlt", Punkt 29).

Zeichen statt Wörter (W12, ab 20.09.2026)

Zwei Zeichen tragen Zustand und Dringlichkeit, und beide stehen so im Style-Guide §7.4:

Der Ring füllt sich — leer bei offen, halb bei in Arbeit, zu vier Fünfteln bei fast fertig, voll mit Haken bei fertig. Drei Zustände fallen absichtlich aus der Reihe: blockiert ist ein durchgestrichener Kreis, verworfen einer mit Kreuz, und dauernd (ab 22.09.2026) ein gestrichelter Ring, der sich nie schließt — in Sepia, dem Ton, den der Style-Guide §6 dem Gedächtnis gibt. Keiner der drei sagt etwas über Fortschritt: blockiert heißt „bewegt sich nicht", verworfen „zählt nicht mehr", dauernd „hat kein Ende". Sie als Füllstufe zu zeichnen wäre eine Lüge in der Form.

Der Rang sind ein, zwei oder drei Winkel übereinander: mittel, hoch, sperrt. Für niedrig wird nichts gezeichnet — ein Zeichen für „unwichtig" verlangt Aufmerksamkeit für seine eigene Unwichtigkeit. Ausnahme seit N132, seit 23.09.2026 auch auf Kachel und Karte (Was fehlt, Punkt 43): Wo „niedrig" von „keine" unterschieden werden muss — Priorität je Bereich und Thema, Knoten im Baum, die Knöpfe des Feldstellers, die Bahn, die Kachel und die Karte —, steht ein blasser Winkel nach unten. sperrt steht in Rot, hoch in Gelb (die Zustandsfarben des Themes), mittel in der Farbe des Bereichs.

Die Nadel heißt angeheftet: „das als Nächstes" — und sie ist auf der Kachel zugleich der Schalter dafür. Seit N132 ist sie das Zeichen anheften aus der Registry, in Gelb, statt eines eigenen Pfads.

Zeichen und Farben je Merkmal (N132, ab 22.09.2026)

Christian am 22.09.2026: „Du solltest doch Icons und visuelles Farbcues machen für schnellere Erkennung." Ring und Rang gab es seit W12; was fehlte, waren Art, Bereich und Zuständigkeit — sie standen als Kennungspräfix, als roher Schlüssel in einer grauen Marke oder als Kürzel da.

Die Art kommt aus dem Ordner und aus nichts sonst (client/arten.ts): 6-fehler ist Fehler, 5-bereiche/wuensche und 3-bens-semester sind Wunsch, 7-langfrist und 5-bereiche/neue-bereiche sind Idee, alles andere Aufgabe. Der Ordner ist die eine Stelle, an der beim Anlegen entschieden wurde, was das ist; ein zweites Kopffeld wäre eine zweite Antwort auf dieselbe Frage. Bens Liste zählt als Wunsch, auch wo ein Fehler darin steht — „Wunsch" heißt hier: kommt von einem Menschen, der Denotato benutzt.

Die Art trägt keine Farbe. Ein roter Käfer wäre schneller gefunden, hieße aber auf einer erledigten Kachel „hier brennt es"; wie es steht, sagt die Kante daneben. Die Form ist die Auskunft.

Der Bereich ist ein Chip nach Guide §15 — Fläche 22 %, Rand 60 % der Bereichsfarbe, Zeichen links, der Titel statt des Schlüssels: „Kalender" statt calendar. Eine Umfärbung in den Einstellungen gilt auch hier. Ein geplanter Bereich steht als „duell (geplant)" mit neutralem Rand; er hat noch keine Farbe, und eine erfundene wäre die, die man später nicht mehr los wird (client/bereichsbild.ts).

Die Zuständigkeit ist Zeichen und Kürzel. Das Zeichen sagt, ob eine Maschine oder ein Mensch den Vorgang hat; welcher Mensch, sagt das Kürzel. Zwei Personenzeichen für Christian und Ben wären eine Unterscheidung, die man lernen müsste.

Weitere Stellen, an denen ein Zeichen ein Schriftzeichen ersetzt: Der Griff der Bahn ist das Zeichen griff (vorher ⠿), ihre Pfeile sind hoch und runter, „zurück zur Übersicht" trägt zurueck (vorher ←), der Winkel im Baum ist weiter, die Rückverweise auf der Kachel zählt das Zeichen verknuepft (vorher ↳), die Pfeile und das Kreuz an einem Schritt sind hoch, runter und schliessen (vorher ↑, ↓, ✕), das Kreuz an einer Notiz ebenso (vorher ×). Die Zeilen der Systemtafel tragen die Scheibe ihres Bereichs; ihre Lage steht in den Zustandsfarben (an grün, ausgeschaltet gelb, nicht gewährt neutral).

Im Baum trägt jeder Knoten das Zeichen seiner Gliederung: ein Ordner das Zeichen seiner Art, ein Bereich sein Zeichen in seiner Farbe (ohne Scheibe — die Zeile ist dafür zu niedrig), ein Zustand den Ring, eine Dringlichkeit den Rang, eine Zuständigkeit ihr Zeichen; ein Thema trägt keines, nur seinen Rang.

In der Themenansicht steht der Rang eines Themas im Prioritätsknopf (Rang und Wort) — kein zweiter Rang davor, der dasselbe noch einmal sagt.

Der siebte Zustand: dauernd (ab 22.09.2026)

Christian am 22.09.2026, auf die Frage nach vierzehn Vorgängen, die niemand je abhaken kann: eigener Zustand.

Woher sie kamen. Beim Durchgehen aller Vorhaben fielen vierzehn auf, deren Abschlussbedingung sich mit dem Einlösen erneuert. Dreizehn sind die Seitenvorgänge S-*: ihr „Fertig, wenn" endet auf „und die Datei nennt acht neue Punkte" — und verify:seiten verlangt von jeder Seitendatei dauerhaft mindestens acht offene Punkte. Wer alle abarbeitet, schreibt acht neue auf, und der Vorgang steht wieder am Anfang. Der vierzehnte war K04, das Nachziehen der Projektübersicht; sein eigener Text sagte seit dem 17.09.2026 „Das ist kein Vorgang mit Ende." Er endete trotzdem: am 23.09.2026, mit dem Einfrieren der Übersicht (N146). Dauernd sind seitdem nur noch die Seitenvorgänge.

Was der Schirm davon zeigt:

Er ist das Spiegelbild von verworfen. Beide zählen aus dem Anteil heraus, aus entgegengesetztem Grund: Verworfenes wird nie gebaut, Dauerndes nie fertig. Rechnete der Balken sie mit, könnte er nur fallen. Der Unterschied: Verworfenes wandert nach erledigt/<jahr>/, Dauerndes bleibt liegen, wo es liegt — es ist nicht abgeschlossen, es hat bloß kein Ende.

Eine Ausnahme, und sie hat einen Namen. Ein dauernd-Vorgang mit liegt-bei: christian zählt weiterhin in der Zahl „wartet auf deine Entscheidung" im Briefing. S-progress ist der Anlass: der Vorgang hat kein Ende und wartet auf eine Wahl. zustand beantwortet die Frage „hat das ein Ende?", liegt-bei die Frage „wer ist dran?" — zwei Fragen, zwei Felder, und die zweite darf die erste nicht verschlucken.

Was die Zahl daneben tut: Der Vorrat sank von 123 auf 109, ohne dass ein einziger Vorgang verschwand. Das ist der ganze Zweck — vierzehn Dauerpflichten, die sich als Rückstand ausgaben, tun es nicht mehr.

Die offene Karte bleibt, auch außerhalb der Sicht (N130, ab 23.09.2026)

Christian am 22.09.2026 (N130): „Stehen bleiben." Nimmt Sicht, Filter, Suche oder Wandwahl den Vorgang der offenen Karte aus der Liste — etwa weil ein Urteil ihn aus „Ideen" nimmt —, schließt die Karte nicht stillschweigend. Sie bleibt stehen, und eine Zeile darunter sagt es mit Wort und Zeichen (Guide §17: Farbe allein reicht nicht): „Dieser Vorgang liegt außerhalb der aktuellen Sicht.", mit dem Zeichen verborgen. Ein Knopf „Sicht zurücksetzen" daneben stellt Sicht auf „Alle", leert Filter und Wandwahl und die Suche in einem Zug — der Vorgang steht danach wieder in der Liste, und die Zeile verschwindet. „zurück zur Übersicht" schließt die Karte wie bisher, unabhängig davon, ob die Zeile steht.

Gemessen wird an gefiltert — derselben Menge, die auch Kacheln, Tafel und Bahn zeigen (Verwaltungsmenue.tsx, geoeffnetAusserSicht). Der Baum ist davon ausgenommen: Er hört Sicht und Filter ohnehin nicht (Was fehlt, Punkt 2) und zeigt einen gefilterten Vorgang oft trotzdem — siehe Was fehlt, Punkt 52.

Die Kachel trägt ihre Knöpfe (20.09.2026)

Christian: „Die Sachen die man ändern kann müssen auf der Kachel sichtbar und changeable sein."

Das kehrt eine Entscheidung von wenigen Stunden vorher um. Am Nachmittag war die Kachel bewusst stumm — sechs Zeilen Auskunft, und wer etwas stellen wollte, öffnete die Karte. Die Begründung war die Übersicht. Sie hat nicht getragen: Wer zwanzig Vorgänge durchsieht, öffnet nicht zwanzigmal eine Karte.

Unter der Trennlinie am Fuß jeder Kachel steht deshalb derselbe Feldsteller wie auf der Karte, nur knapp: sieben Ringe für den Zustand, vier Ränge für die Dringlichkeit, drei Kürzel für die Zuständigkeit — Claude · Christian · Ben (seit N182; vorher ich · du · Ben). Keine Wörter, weil sieben Wörter nicht in eine Reihe passen; jedes Zeichen trägt sein Wort im Tooltip und im aria-label.

Es ist derselbe Baustein, nur enger gestellt (knapp), und das ist Absicht: Ein zweiter Steller mit denselben Werten und eigener Logik wäre die Stelle, an der Kachel und Karte eines Tages Verschiedenes behaupten.

Was nicht auf die Kachel kommt, und warum:

Damit ist die Kachel kein Knopf mehr, sondern ein Behälter: Ein Knopf im Knopf ist kein gültiges Dokument, und ein Klick auf den Ring hätte sonst zugleich die Karte geöffnet. Anklickbar zum Öffnen ist jetzt der Titel. Vorgelesen wird der ganze Vorgang an dieser einen Stelle, nicht viermal in Bruchstücken.

Die Kachelwand ist dafür von 240 auf 280 px je Spalte gegangen — darunter brach die Zustandsreihe um, und aus einer Zeile Knöpfe wurden zwei. In der Tafel bleiben dieselben Kacheln stumm: dort stehen sie in schmalen Spalten, und drei Knopfreihen je Stück machten aus der Verteilung, die sie zeigen soll, eine Rolle.

Am Telefon ist jeder dieser Knöpfe so groß wie die Zielfläche (44 px, Marke layout.zielflaeche; Guide §16.1, E17, 27.09.2026). Der Blick vom 23.09.2026 maß die Ringe mit 20 × 20 px, die Nadel mit 16 × 16, „löschen" mit 56 × 24 und den Titel einer Bereichskachel mit 19 px Höhe. Unter pointer: coarse wird der knappe Steller quadratisch — sieben Ringe passen mit ihren Lücken in 304 px —, Nadel, Titel und „löschen" bekommen dieselbe Mindesthöhe, ebenso beide Zeilen des Baums und die Wertknöpfe der Filterleiste. Am Rechner bleibt alles, wie es war.

Referenzen in beide Richtungen (W12, ab 20.09.2026)

Auf jeder Karte steht, woran der Vorgang hängt (siehe: aus dem Dateikopf) und was daran hängt (die Gegenrichtung). Beides als Pillen mit dem Ring des Ziels; ein Klick springt dorthin.

Auf der Pille steht seit dem 20.09.2026 der Titel, nicht die Kennung. Christian: „Ich brauche bessere Übersicht (Referenzen nach Namen nicht ID)." Vorher stand dort BE08 und der Titel nur im Tooltip — also genau die Auskunft, die man sucht, hinter der Geste, die man dafür nicht machen will.

Eine Kennung ist eine Adresse, kein Name. Sie ist richtig im Dateinamen, im Commit und im siehe:-Feld, weil sie dort kurz und eindeutig sein muss; auf einem Schirm beantwortet sie keine Frage. Sie ist nicht weg, nur an ihren Platz gerückt: ins Tooltip (BE08 · Rückfall auf die Umgebung ist weg) und ins aria-label. Lange Titel werden auf eine Zeile gekürzt, damit aus vier Verweisen nebeneinander nicht vier Zeilen untereinander werden.

Das Feld siehe: gab es seit dem 17.09.2026 in jedem Dateikopf und kam in der Oberfläche nie an. Die Gegenrichtung gab es überhaupt nicht: BE01 nennt B01, aber B01 weiß nichts von BE01 — und wer B01 ansieht, muss wissen, dass drei andere Vorgänge darauf warten.

Eine Kennung ohne Vorgang bleibt Text, durchgestrichen und nicht klickbar: „Ein Verweis, der nirgendwohin führt, ist schlimmer als keiner."

Dort steht dann die Kennung — und das ist kein Widerspruch zur Regel von oben, sondern dieselbe Regel: Einen Titel gibt es nicht, weil es den Vorgang nicht gibt. Die Kennung ist das Einzige, was von ihm übrig ist, und genau sie braucht man, um zu suchen, wohin er verschwunden ist.

Unterpunkte (W12, ab 20.09.2026)

Trägt eine Vorgangsdatei einen Abschnitt ## Schritte mit Markdown-Kästchen, stehen sie auf der Karte als abhakbare Liste, mit eigenem kleinen Balken darüber. Das Feld „Noch ein Schritt …“ darunter ist seit dem 10.10.2026 eine Zeile unter einer Haarlinie und kein eigener Kasten mehr — es steht in der Karte des Vorgangs (ES-261010-restliche-kartenraster).

Seit dem Abend des 20.09.2026 lassen sie sich auch schreiben. Christian: „Erstellung neuer Unterpunkte und so muss möglich sein." Anlegen, umformulieren, streichen, höher und tiefer schieben — vier Griffe mehr als der eine, den es bis dahin gab.

Nichts davon landet sofort in der Datei. Alles liegt als Überlagerung in admin.vorgangsschritte und wartet darauf, dass ich es eintrage. Wo etwas wartet, bekommt die Zeile einen Punkt; ein Schritt, den es nur hier gibt, dazu das Wort neu. Die Nummer ist seither die Kennung eines Schritts und nicht mehr seine Stellung — das ist der Preis dafür, dass man umsortieren kann, ohne dass jeder gesetzte Haken auf die falsche Zeile rutscht.

Die vier neuen Griffe sind einzeln abschaltbar. Fehlt der passende Rückruf, fehlt der Knopf. Eine Karte, die nur zeigt, soll keine Knöpfe tragen, die ins Leere gehen.

Der Balken zählt nur die Kästchen, nicht den Zustand des Vorgangs. Beides zusammenzuziehen wäre verführerisch („vier von sechs Schritten heißt fast fertig") und falsch: Der letzte Schritt ist selten der kleinste.

Der Bauzustand (Reiter „System")

Oben eine Summenzeile: Bereiche — 17 an · 0 ausgeschaltet · 0 nicht gewährt, alle drei Lagen einzeln und auch mit einer Null davor — „0 nicht gewährt" ist eine Auskunft, ein fehlendes Wort wäre keine. Darunter die Tafel: wie viele Bereiche, Endpunkte, Nachweise, Seitenbeschreibungen und Wanderungen es gibt. Die drei Lagen aus N63 stehen getrennt, weil sie sich ähnlich sehen und Verschiedenes bedeuten: nicht gewährt beantwortet die API mit 404, ausgeschaltet mit 403.

Die Lage rechnet der Rechtebaum (N149, 23.09.2026): leseSystemstand fragt je Bereich bereichslage am Knoten seiner Deklaration — dieselbe Rechnung wie Leiste, Wege und rechte_baum (00-rahmen.md §1). Bis dahin rechnete die Tafel selbst, mit featurelage am Merkmal, für Tutor, Material und Noten also am Studium. Heute ergeben beide dasselbe, weil der Baum diese Knoten aus dem Studium ableitet. verify:verwaltung Punkt 22 vergleicht die Tafel für drei erfundene Konten mit dem Baum und wird rot, sobald sie davon abweicht — etwa mit einer eigenen Rechnung, die nur die Gewährung fragt.

Die Liste zeigt zuerst nur die Abweichungen (seit 22.09.2026) — jeder Bereich, der aus ist oder nicht gewährt, mit seiner Pille. Ist keiner es, steht dort Keiner ist ausgeschaltet oder nicht gewährt. Die Zeilen „an" liegen hinter „alle N zeigen": Vorher musste man sie absuchen, um die eine zu finden, die nicht an war. Weg vom ersten Blick darf nur, was grün ist (N128).

Antworten und ihre Schemata (D35, N389, 28.09.2026) — der Abschnitt unter der Liste. Seine Summenzeile nennt die Lage des Abstreifens als Pille (Trockenlauf in Warnfarbe, solange ABSTREIFEN aus ist, sonst streift ab in Grün), die Zahl der Befunde und der Routen („1 Befund", „2 Befunde") und seit wann gezählt wird — dem Start des Prozesses, denn die Befunde liegen im Speicher und beginnen nach einem Neustart leer. Darunter je Befund eine Zeile: die Route in Schreibmaschinenschrift, die Art als Pille (würde abstreifen oder streift ab in Warnfarbe, weicht ab in Infofarbe), × n mit dem letzten Zeitpunkt als Titel und darunter die Stellen als Feldpfade, nie Werte. Sind es mehr als zwölf, klappt „alle N zeigen" den Rest auf. Ohne Befund steht dort Keine Befunde seit dem Start.; ohne gelesenen Stand nur die Summenzeile mit ihren Strichen, damit „Noch nicht gelesen." nicht zweimal dasteht. Der Abschnitt ist der Ort, an dem nach N389 entschieden wird, ob das Abstreifen scharf geschaltet wird.

Der Satz, woher die Zahlen kommen, steht hinter dem Aufklapper „Woher die Zahlen kommen".

Jede Zahl dort ist gezählt und keine gepflegt — aus den Registern, der Pfadtabelle und dem Dateisystem. Eine Zahl, die jemand von Hand nachtragen müsste, wäre am Tag danach falsch.

Ohne gelesenen Stand stehen Striche — in der Summenzeile (Bereiche — an · — ausgeschaltet · — nicht gewährt) und an der letzten Wanderung, darunter „Noch nicht gelesen." Nach einem Ladefehler stand dort „0 an · 0 ausgeschaltet · 0 nicht gewährt": dieselbe Falschaussage, gegen die das Band am 20.09.2026 die Striche bekam.

Der erste Blick (22.09.2026, W15 ab 23.09.2026)

Unter „Vorhaben" steht seit W15, von oben: Kopf mit Suchfeld nur in Kacheln und Tafel · Abschnitte · Ansichtsreiter, am rechten Ende der Knopf + Neu · das Band · die Zeile der offenen Einfälle · die Entwurfszeile · die Sichtleiste mit der Pille Filter · die Ansicht. Die beiden Zeilen fehlen, solange nichts offen ist und nichts wartet.

Hinter + Neu liegt das Anlegefach des Rahmens mit zwei Teilen: oben das Einfallsfeld (N190), darunter das Entwurfsformular. Beides stand früher offen über jeder Ansicht, auch wenn man nur nachsehen wollte — bis zum 22.09.2026 das Formular mit sechs Feldern, einer Knopfreihe und einem Erklärsatz, bis zum 23.09.2026 das Einfallsfach mit Feld und drei offenen Einfällen, am Telefon 286 px vor der ersten Kachel. Der Knopf steht nur unter „Vorhaben"; ?neu in der Adresse klappt das Fach von selbst auf, ein Wechsel nach „System" klappt es zu.

Wer über „+ Neu" oder ?neu aufklappt, hat den Zeiger im Einfallsfeld. Einen Einfall zu notieren ist hier der häufigste Handgriff, und Christian hat den einen Klick mehr dafür in Kauf genommen (N190); danach kostet er nur Tippen und Eingabe. Das Feld ist beim Senden readOnly statt disabled und behält so den Zeiger, und eine Statuszeile sagt, dass der Einfall jetzt vorn steht. Ein Satz, der nicht notiert werden konnte, bleibt im Feld stehen — bis dahin war er weg. Ist die Ablage leer, steht unter „Die Ablage ist leer." der Knopf Ersten Vorgang anlegen, der das Fach öffnet und den Zeiger ins Titelfeld des Formulars setzt — wie die Leerzustände im Gerüst (N37.1).

Nicht gelesen ist nicht leer (Nachbesserung 22.09.2026). Ist kein Stand da — der Server hat nicht geantwortet —, steht in jeder Ansicht „Der Stand ist nicht gelesen — hier steht nichts, bis er ankommt.", ohne Anlegeknopf. Vorher stand dort „Die Ablage ist leer." mit „Ersten Vorgang anlegen" (in den Bereichen: „Kein Bereich trägt einen Vorgang."), während das Band daneben richtig Striche zeigte — eine volle Ablage als leer ausgegeben, mit einer Einladung, sie doppelt zu füllen. Die Gliederungsleiste des Baums bleibt dabei stehen: Der letzte Stand ist mit seiner Gliederung aufgehoben, und wer zu ihr zurückgeht, hat ihn wieder.

Wartende Entwürfe verschwinden nicht mit dem Fach. Solange es zu ist, steht unter den Einfällen eine Zeile: „1 Entwurf wartet auf seine Datei: W99 Wochenrückblick als eigene Karte". Ein Klick darauf öffnet das Fach, rollt dorthin und gibt den Zeiger der Liste der Entwürfe; im Fach stehen sie oben, mit Wegtun. Solange das Fach offen ist, fehlt die Zeile — dieselben Entwürfe stünden sonst zweimal untereinander. Das Wegtun kommt nicht mit auf die Zeile: Es ist unumkehrbar, und ein unumkehrbarer Knopf bekommt keinen kürzeren Weg (N128).

Von den Einfällen steht vorn nur eine Zeile (N190): „2 offene Einfälle: Wochenrückblick als Karte · Mensaplan im Kalender". Sie klappt an Ort und Stelle auf und öffnet das Fach nicht — nachsehen, was notiert ist, ist kein Anlegen. Aufgeklappt stehen alle offenen, jeder mit seinem Kreuz zum Wegtun; eine zweite Grenze dahinter wäre ein zweiter Klick für dieselbe Frage. Ist keiner offen, fehlt die Zeile. Was schon ein Vorgang wurde, steht im Fach unter dem Feld hinter „12 übernommen zeigen" — nur dort sieht man, dass aus einem Satz ein Vorgang wurde.

Eine Karte rollt in den Blick. Wer eine Kachel, eine Tafelkarte, eine Bahnkarte oder eine Baumzeile anklickt, bekommt die Karte oben im Blick, statt über der Stelle, an der er war, außer Sicht. „zurück zur Übersicht" bringt ihn an genau die Stelle zurück, von der er kam — auch wenn er vorher in der Karte über Verweise zu anderen Karten gesprungen ist; der Rückweg bleibt der zur Übersicht. Hat er zwischendurch die Ansicht gewechselt, bleibt der Blick, wo er ist: Den alten Ort gibt es dort nicht. Gerollt wird die Fläche des Rahmens, nicht das Fenster (client/rollen.ts).

Gemessen im Prüfstand (Rechner 1440 × 900, Telefon 390 × 844), wo der erste Inhalt der Ansicht beginnt:

Nachgemessen mit W15 (23.09.2026), mit dem Prüfkonto von /ansehen und einem eigenen Messskript — deshalb nur in sich zu vergleichen, nicht mit der Tabelle darüber. Gemessen ist die Oberkante des ersten Inhalts der Ansicht; leer heißt ohne Einfälle und Entwürfe, gefüllt mit fünf offenen Einfällen und einem wartenden Entwurf:

Jetzt steht in jeder Ansicht, auf beiden Geräten und auch gefüllt, Inhalt im ersten Fenster (900 px am Rechner; am Telefon 844 px, die untere Leiste beginnt bei etwa 790 px). Vorher war es am Telefon nur in Bereichen und Baum so, und gefüllt in keiner Ansicht.

Was es an Klicks kostet:

Die Bahn — was als Nächstes kommt (21.09.2026)

Seit N289 (25.09.2026) auf keinem Schirm. Planbahn.tsx bindet niemand mehr ein; es bleiben ihr Test, die Route /api/verwaltung/bahn und das MCP-Werkzeug verwaltung_bahn (Punkt 61 unter „Was fehlt“). Der Abschnitt beschreibt, was sie war.

Ein fünfter Ansichtsreiter, und er steht vorn und ist damit die Vorgabe — weil er die Frage beantwortet, mit der man hierherkommt: was kommt als Nächstes?

Der gewählte Reiter steht in der Adresse (?v=kacheln) und nicht in einer Einstellung; ein gespeicherter Verweis zeigt deshalb weiter auf das, worauf er zeigte, auch nachdem die Bahn davorgerückt ist.

Christian am 21.09.2026: „Mach bitte in der Verwaltung eine Art Flussdiagramm damit ich sehe was du als nächstes alles vor hast und ich neuordnen kann."

Von oben nach unten eine Reihe schmaler Karten: Zustandsring, Titel, darunter Art, Kennung, der Rang der Dringlichkeit und — wenn angeheftet — die Nadel (seit N132 Zeichen statt Wörter, das Wort im Tooltip), und — wo es etwas gibt — die Zeile „wartet auf W08, C35". Genannt wird nur, was noch offen ist; ein erledigter Vorgang hält nichts mehr auf, und ihn zu nennen wäre eine Warnung ohne Anlass. Offen heißt offen in der ganzen Ablage, nicht in der Sicht (23.09.2026): Die Zeile rechnete bis dahin mit dem Gezeigten, und in der Sicht „Bei Christian" verschwand „wartet auf W08", weil der Filter W08 ausblendete. Jetzt fragt die Bahn alle gelesenen Vorgänge (bekannte).

Erledigtes und Verworfenes steht nicht in der Bahn (N199, 23.09.2026). Die Rangfolge fragte nicht nach dem Zustand, und „sperrt" sortiert vor allem: Achtzehn der zweiundzwanzig Vorgänge mit „sperrt" waren erledigt und standen oben, vor dem ersten, das noch kommt. Christian hat „Bahn ohne Erledigtes" gewählt — die Bahn beantwortet was kommt als Nächstes?, und Erledigtes kommt nicht mehr. dauernd bleibt, denn eine Pflicht ohne Ende ist weiter zu tun. Bleibt nichts übrig, steht dort „Hier steht nichts, was noch zu tun wäre."

Der Satz über den Karten liegt hinter dem Aufklapper „Wie die Reihenfolge entsteht" (W15, 23.09.2026): Offen standen am Telefon 90 px Text vor der ersten Karte. Er sagt auch, dass Erledigtes hier fehlt und wo es steht — in Kacheln und Tafel. Band, Systemtafel und Bahn tragen denselben Aufklapper (client/Erklaerung.tsx). Wer baut, heißt darin Claude und nicht „ich" (N182): „das Erste ist das, was Claude als Nächstes baut … und ab dann baut Claude in dieser Reihenfolge".

Umsortiert wird durch Ziehen am Griff oder mit den beiden Pfeilen an jeder Karte. Beides schreibt sofort — kein „Speichern"-Knopf: Wer eine Karte zieht, hat entschieden, und ein Knopf danach wäre eine zweite Entscheidung über dieselbe Sache.

Geschickt wird jedes Mal die ganze sichtbare Reihenfolge, nicht die eine gezogene Karte. Die Reihenfolge ist eine Eigenschaft der Bahn und kein Merkmal eines Vorgangs.

Was die Bahn nicht ist: ein Graph aller Abhängigkeiten. Ein Netz aus hundertsiebzig Knoten ist hübsch und beantwortet keine Frage. Was ein Vorgang braucht, steht als schmale Zeile an seiner Karte — dort, wo man es liest, bevor man zieht.

Verhältnis zum Anheften: Das Anheften sagt „das als Nächstes" und ist ein Schalter; die Bahn sagt „das vor jenem" und ist eine Ordnung. Beides steht nebeneinander, und wer nichts gezogen hat, sieht die natürliche Rangfolge — angeheftet zuerst, dann nach Dringlichkeit. planRang: null heißt „noch nie angefasst" und nicht „ganz hinten", denn sonst spränge ein neu angelegter Vorgang vor alles Gezogene.

Endpunkt: POST /api/verwaltung/bahn. MCP: verwaltung_bahn.

Löschen (22.09.2026, N133)

Christian: „füge einen Löschen-Button hinzu damit ich auch welche die nicht mehr relevant sind löschen kann."

An jeder Karte ganz unten rechts und an jeder einfachen Kachel rechts in der Kopfzeile steht löschen. Ein Klick fragt nur — ja, weg und doch nicht, an derselben Stelle, kein Fenster (Wegtun, wie überall in Denotato). Erst der zweite merkt vor.

Vormerken, nicht löschen. Der Vorgang verschwindet sofort aus allen Ansichten, Zahlen und Listen — ein Knopf, der erst am nächsten Morgen wirkt, sähe aus wie einer, der nicht geht. Er steht dann nur noch im Fach „Zum Löschen vorgemerkt" über der Sichtleiste, durchgestrichen, mit doch behalten (bis zum 26.09.2026 „zurücknehmen", I07, N308). Die Datei entferne ich beim nächsten Lauf, wenn verwaltung_offen loeschen: true meldet; danach ist der Weg zurück git log.

Gelöscht ist nicht verworfen. Verworfen heißt „das bauen wir nicht" und bleibt als Datei in erledigt/ stehen, als Beleg. Gelöscht heißt „war nie Arbeit an Denotato oder ist es nicht mehr": Die Datei ist weg, die Kennung bleibt vergeben — in docs/vorhaben/GELOESCHT.md mit Titel, Tag und Grund, damit ein Commit, der C01 nennt, in drei Monaten nichts anderes meint. Das Anlegefach schlägt deshalb die nächste Nummer über den gelöschten vor.

Nicht an der Projektkachel, und das ist Absicht: Ein Projekt zu löschen nimmt seinen Teilen den Vater. Das entscheidet man an der Karte, wo die Teile daneben stehen, nicht im Vorbeigehen über die Wand. In der Tafel bleiben die Kacheln stumm wie bisher.

Die Tabelle ist admin.vorgangsaenderungen, eine Zeile mit feld = 'loeschen' — keine Wanderung. Zurücknehmen löscht die Zeile.

Endpunkt: POST /api/verwaltung/loeschen. MCP: verwaltung_loeschen.

Was man tun kann

Reiter ordnen (OE10, N500): Wer Vorgaben für alle setzen darf, ordnet und blendet die Reiter über „Bearbeiten“ im Kopf; die Folge steht in oberflaeche.reiter unter admin (die Kategoriespalte), Ansichten je Kategorie admin/<kategorie> (Rahmen §3).

Drei Urteile und kein Häkchen. „Später" ist der Grund für die Karte: Ein Ja/Nein zwingt dazu, eine gute Idee zur falschen Zeit abzulehnen, und dann kommt sie nie wieder.

An jeder Antwort steht, ob sie schon in einer Vorgangsdatei steht („noch nicht übernommen"). Das ist keine Warnung, sondern die Auskunft darüber, ob ich sie schon gelesen habe. Sagt er nach meinem Nachtrag noch etwas, taucht der Vorgang wieder als offen auf.

Stellen heißt nicht schreiben (W12, ab 20.09.2026)

Seit dem 20.09.2026 lässt sich hier alles anpassen — Zustand, Dringlichkeit, Zuständigkeit, Schritte, und ein Vorgang lässt sich anlegen. Christian: „damit ich streng genommen gar nicht mehr mit dir reden müsste sondern du im Arbeitsmodus immer da rein schaust."

Und trotzdem entsteht hier keine zweite Ablage. Was er stellt, ist ein Auftrag an mich, kein Zustand: eine Zeile mit uebernommen_am IS NULL in admin.vorgangsaenderungen, admin.vorgangsschritte oder admin.vorgangsentwuerfe. Der Schirm zeigt sofort den gestellten Wert — daneben ein Punkt, der sagt „steht noch in keiner Datei". Sobald ich ihn eingetragen habe, ist die Zeile Geschichte.

Denotato schreibt die Dateien nicht selbst, und der Grund ist betrieblich: Die Auslieferung läuft über git pull --ff-only origin beta (betrieb/hetzner/ausliefern.sh:51). Ein Backend, das ins Arbeitsverzeichnis schreibt, lässt den nächsten Pull scheitern — nicht sichtbar an der Verwaltung, sondern Stunden später an der Auslieferung.

Was hier nicht geht: einen Vorgang abhaken und nach erledigt/ verschieben, den Titel ändern (die Route kann es, der Schirm nicht) oder ein eltern: setzen. Das geschieht in den Dateien — im Code-Commit oder spätestens im Doku-Commit am Ende des Auftrags, vor dem Push (eigenständig: am Ende der Welle, N146; bis zum 23.09.2026 hieß es „im selben Commit"). Löschen lässt sich seit dem 22.09.2026 auslösen — ausgeführt wird es trotzdem in den Dateien, von mir (siehe „Löschen" oben).

Ein Bereichswechsel löst das Thema mit (N132, ab 23.09.2026, Was fehlt Punkt 42). Themen gelten je Bereich; wer bereich über /api/verwaltung/stellen oder verwaltung_stellen stellt, stellt im selben Zug auch thema auf - — zwei Zeilen in admin.vorgangsaenderungen, eine Transaktion (stelleFeld, server/verwaltung.ts). Ohne das trüge ein Vorgang unter dem neuen Bereich ein Thema, das dort entweder verwaist ist oder zufällig eines trifft, das etwas anderes meint. Der Schirm selbst bietet bereich als Feld noch nicht an (Punkt 16) — betroffen ist bisher, wer über MCP oder API stellt.

Ein Teil-Vorgang lässt sich anlegen (21.09.2026)

Im Anlegefach (hinter + Neu) steht ein Feld „Teil von" — die Kennung des Projekts, etwa W08. Leer heißt „kein Teil von etwas", und das ist der Normalfall.

Bis dahin ging das nicht: Jeder Vorgang trug seit dem 20.09. ein eltern: im Kopf, und /admin zeigte Projekte mit ihren Teilen — aber anlegen ließ sich ein Teil weder hier noch über MCP. Er entstand nur, wenn ich die Datei von Hand schrieb. Christian: „Erstellung neuer Unterpunkte und so muss möglich sein."

Geprüft wird der Vater erst beim Anlegen der Datei. Die Vorgänge stehen in Dateien (N80), nicht in dieser Datenbank; ein Fremdschlüssel hätte nichts, worauf er zeigen könnte. Ein erfundener Vater fällt verify:vorhaben auf — dort, wo die achtzehn Regeln stehen. Die eine Regel, die sich ohne Blick in die Dateien prüfen lässt, steht schon in Migration 65: niemand ist sein eigener Vater.

MCP: verwaltung_entwurf mit eltern.

Scheitert das Anlegen, bleibt „Anlegen" im Entwurfsfach bedienbar (F28b, 23.09.2026): Der Knopf setzt seinen Laufmerker über useBusyLock, das ihn in einem try/finally freigibt, statt bei einem geworfenen Fehler gesperrt stehen zu bleiben. Der Ladezustand des ganzen Schirms hängt dagegen an useMenuScreen und nicht an der Komponente selbst; ein try/finally sichert auch ihn ab, ohne einen Riegel gegen den Doppelklick zu brauchen.

Woher die Daten kommen

/api/verwaltung (VERWALTUNG) liefert den ganzen Schirm in einer Antwort — Bahnen, Stellen, Einfälle, Entwürfe, die Bereichs-Wand (bereichswand, fertig gerechnet), je nach Gliederung anders gebündelt. Das Urteil am Bereich geht über /api/verwaltung/bereichsurteil (VERWALTUNG_BEREICHSURTEIL) — urteil: null nimmt es zurück.

Der Leitstand liest nicht aus dieser Antwort, sondern eigens über /api/verwaltung/leitstand (VERWALTUNG_LEITSTAND) und /api/verwaltung/leitstand/figures (VERWALTUNG_LEITSTAND_FIGURES); Befehle gehen über /api/verwaltung/leitstand/command (VERWALTUNG_LEITSTAND_COMMAND). Die Herkunft jeder Zahl steht im Abschnitt „Leitstand“ oben.

Seit N132 trägt jede Wandkachel prioritaet und themen (Kennung, Titel, Priorität, angelegt, Stand, offene), jeder Vorgang thema, bereichsprioritaet und themaprioritaet, und jeder Baumknoten prioritaet. Die Priorität eines Bereichs oder Themas geht über /api/verwaltung/prioritaet (VERWALTUNG_PRIORITAET, { bereich, thema?, prioritaet } — prioritaet: null nimmt sie zurück), Anlegen, Umbenennen und Entfernen eines Themas über /api/verwaltung/thema (VERWALTUNG_THEMA, { bereich, tun: anlegen | umbenennen | wegtun, kennung?, titel? }). Die Zuordnung eines Vorgangs geht über VERWALTUNG_STELLEN mit feld: thema. MCP: verwaltung_prioritaet, verwaltung_thema; verwaltung_offen liefert prioritaeten und themen mit, damit die Nacht die Reihenfolge der Arbeit danach richtet.

Hinweis: Hier stand /api/verwaltung/stand — den Weg gibt es nicht (korrigiert am 21.09.2026). Der Stand kommt unter der Wurzel des Bereichs; admin/client/anfragen.ts ruft APIPaths.VERWALTUNG, und verwaltung.md hat daneben einen Namen geschrieben, der zum Speicher passt (admin.stand) und nicht zur Adresse. Aufgefallen, als verify:seiten anfing, auch hingeschriebene Pfade gegen APIPaths zu prüfen (F23).

Aufgehoben wird unter admin.stand (G03, 21.09.2026, Rahmen 7), und zwar mitsamt der Gliederung, unter der er geholt wurde. Der Schirm zeigt denselben Bestand in vier Bündelungen; ein Stand aus der einen unter der Überschrift der anderen wäre keine Auskunft, sondern eine Verwechslung. Passt die aufgehobene Gliederung nicht zur gewählten, gilt er als nicht vorhanden — dann steht da nichts, und das stimmt.

Die Eule: „Einen Vorgang zusammenfassen“ (KI21, N372)

Der offene Vorgang steht im Hash der Adresse (/admin#<Kennung>, vorgangAusAdresse); daraus liest die Eule ihren Gegenstand (client/gegenstand.ts). Den Vorgang liest der Server nur mit dem Merkmal admin: Kopf, Verweise mit ihrem Zustand und höchstens 8 000 Zeichen der Datei aus docs/vorhaben. Eine Kennung, die es nicht gibt, wird abgewiesen wie ein unbekanntes Angebot.

Was fehlt

1. Kein Verlauf. Gebaut am 20.09.2026: eine Zeile je Tag (admin.fortschritt, Migration 54), im Band als Linie mit „+11 diese Woche". Offen bleibt: Der Verlauf zeigt nur erledigt, nicht die drei Zahlen nebeneinander — und ein Tag, an dem man ins Minus rutscht (ein Vorgang wird wieder geöffnet), sieht aus wie ein Messfehler.
2. Der Baum hört Sicht, Filter und Suche nicht. Er ist seit dem 20.09.2026 eine Ansicht neben den anderen, liest aber weiter den fertigen Baum vom Server statt die gefilterte Liste. Seit dem 22.09.2026 stehen die drei über ihm deshalb gar nicht mehr da, statt nichts zu bewirken — ehrlich, aber keine Lösung: Wer die blockierten in ihrer Gruppe sehen will, kann es nicht. Der Filter müsste die Knoten mitnehmen, in denen ein Treffer liegt, und die leeren wegfallen lassen; dann kämen Sicht, Filter und Suche zurück.
3. Die Hierarchie ist zwei Ebenen tief, und das ist eine Setzung. verify:vorhaben weist ein Enkelkind zurück. Für W08 und NB08 reicht das; ob es für ein Vorhaben reicht, das selbst aus Vorhaben besteht, ist unbeantwortet — und die dritte Ebene nachzuziehen heißt, jeden Balken und jede Kachel neu zu denken.
4. Ein eltern: lässt sich nur in der Datei setzen. Der Schirm zeigt Projekte und Teile, aber er verschiebt keinen Vorgang in ein Projekt und keinen heraus. Das ist die einzige Gliederungsänderung, die das Pult nicht kann — und die, für die man es am ehesten aufmacht.
5. Keine Schätzung, kein Datum. Ein Vorgang hat keinen Aufwand und kein Ziel, also kann der Balken nicht sagen, wann er voll ist. Eine Angabe wie bei den Aufgaben (small/medium/large) wäre der kleinste Schritt dorthin.
6. Die Sperrwirkung steht nur im Text. ◐ Halb gebaut am 20.09.2026: siehe: ist jetzt in beide Richtungen sichtbar („hängt an" / „daran hängen"). Was weiter fehlt, ist die Bedeutung der Kante: siehe: heißt „verwandt", nicht „blockiert". C02 → B01 → BE01 ist eine Kette, in der jedes Glied das nächste sperrt, und der Schirm zeigt sie wie jede andere Verwandtschaft. Ein zweites Kopffeld (sperrt:) wäre der kleinste Schritt, ein Graph die ehrlichere Darstellung.
7. Sicht und Filter merken sich ihre Wahl nicht. Der Ansichtsreiter steht in der Adresse (?v=), die Sicht, der Feldfilter und die Gliederung des Baums nicht; wer neu lädt, ist wieder bei „Alle" und „nach Ablage". useMenuScreen kennt dafür keinen Parameter, und einen weiteren in den Hook zu schreiben wäre eine Änderung an einer Stelle, die elf Schirme teilen.
8. Die Suche kennt keine Tippfehler. Umlaute und Akzente sind egal, aber verwlatung findet nichts. Bewusst (die Begründung steht oben) — wenn sich zeigt, dass zwei Buchstaben Abstand häufiger sind als befürchtet, ist ein Abstandsmaß auf dem Titel allein, nicht auf der Kennung, der nächste Versuch.
9. Kein Ort für neue Ideen. Gebaut am 20.09.2026. Über der Liste steht ein Feld „Mir fällt gerade ein…" — ein Satz, kein Formular. Offen bleibt: Ein Einfall lässt sich nicht bearbeiten, nur zurücknehmen und neu schreiben.
10. Die Ablage muss neben dem Server liegen. Der Leser sucht docs/vorhaben/ vom Modulpfad aus nach oben. Auf einem Rechner ohne Repository bleibt der Bereich leer; er sagt es, aber er kann es nicht ändern.
11. Kommentare lassen sich nicht zurücknehmen. deleted_at steht in der Tabelle, aber kein Weg führt dorthin. Absichtlich fürs Erste: Ein Steuerungssatz, der verschwindet, ist schlimmer als einer zu viel.
12. Nur ein Mensch. Urteile hängen an user_id; zwei Menschen mit feature.admin sähen verschiedene Antworten auf dieselbe Frage, ohne dass irgendwo steht, dass es zwei gibt.
13. Die Systemtafel zählt, sie prüft nicht. Sie sagt, wie viele Nachweise es gibt — nicht, wie viele davon grün sind. Dafür müsste jemand sie laufen lassen, und das ist eine Sache von Minuten, keine von Millisekunden; es gehört in einen Zeitgeber, der das Ergebnis ablegt.
14. Kein Stand der Zweisprachigkeit. verify:sprache kennt die Zahl, die Tafel nicht.
15. Der Fortschritt der Teile wird zweimal gerechnet. standDerTeile in client/Projektkachel.tsx wiederholt fortschrittDerTeile aus server/vorhabenlesen.ts, weil dieselbe Datei Dateien von der Platte liest und damit für die Oberfläche unerreichbar ist. verify:verwaltung rechnet nur die Serverseite nach. Die saubere Stelle wäre @shared/types/verwaltung.ts — beide Rechnungen sind reine Logik über Typen, die dort schon stehen.
16. Der Titel lässt sich nicht ändern. Die Route /api/verwaltung/stellen nimmt feld: 'titel' entgegen, der Schirm bietet es nicht an: Ein Titel ist ein Satz und braucht ein Eingabefeld, kein Knopfband. Dasselbe gilt für bereich.
17. Ein Entwurf lässt sich nicht bearbeiten. Wer sich vertippt, nimmt ihn zurück und legt einen neuen an — dieselbe Lücke wie beim Einfall (Punkt 9), und aus demselben Grund noch offen.
18. Die Tafel kennt kein Ziehen. Bewusst (siehe oben) — aber wenn sich zeigt, dass der Umweg über die Karte bei zwanzig Änderungen am Stück nervt, ist das Argument neu zu prüfen.
19. Kein Zeichen für „viele hängen daran". Die Kachel zählt die Rückverweise als Verknüpfungszeichen mit einer 3, und das ist eine Zahl unter anderen. Ein Vorgang, der sechs andere freigibt, ist aber der, den man zuerst anfassen sollte — das gehört in die Rangfolge, nicht in eine Zeile.
20. Der Rückfall gilt je Gliederung. Aufgehoben wird nur die zuletzt geholte; wer bei einem Ausfall auf eine andere Bündelung umschaltet, sieht nichts, obwohl derselbe Bestand dahinterliegt (G03, Rahmen 7).
21. Keine Bereichs-Wand, keine Bauentscheidung je Bereich. Gebaut am 22.09.2026 (W14, entschieden als N127): die Wand in zwei Reihen, das Urteil je Bereich in admin.bereichsurteile, und es wirkt zuerst. Offen bleibt: Ein Vorgang kann sich dem Urteil seines Bereichs nicht entziehen — es gibt kein „trotzdem bauen" am einzelnen Vorgang; wer eines will, nimmt das Urteil am Bereich zurück und stellt die übrigen einzeln. Bewusst so, weil Christian das Bereichsurteil „vorerst unabhängig von den Einzeleinstellungen" gesetzt hat.
22. Die Karten sind noch ein Reiter, und die Kacheln sind noch die Vorgabe. Gebaut am 22.09.2026: Die Reiter sind Bereiche · Kacheln · Tafel · Bahn · Baum, die Wand ist die Vorgabe, „Karten" ist weg, ?v=karten fällt auf die Vorgabe zurück. Seit N289 (25.09.2026) stehen die Bahnen vorn und sind die Vorgabe; die Bahn ist kein Reiter mehr.
23. Die Wand hört Sicht, Filter und Suche nicht. Sie zählt immer alles; wer nach „blockiert" filtert und auf „Bereiche" wechselt, sieht dieselben Balken wie ohne Filter. Dieselbe Lücke wie beim Baum (Punkt 2), aus demselben Grund: Sie liest, was der Server rechnet.
24. Eine geplante Kachel kennt ihre Lage nicht. geplant:duell hat keine Deklaration im Register, also keine Marke an/aus; sie trägt nur geplant. Sobald der Bereich gebaut ist, verschwindet die Marke und die Lage erscheint — das Urteil bleibt, weil der Schlüssel ohne Präfix gespeichert ist.
25. Die Bereichswahl steht nicht in der Adresse. Der Klick auf einen Kacheltitel setzt einen Zustand im Schirm, keinen Parameter; wer die Kacheln mit Bereichspille neu lädt, ist wieder bei allen. Dieselbe Grenze wie bei Sicht und Filter (Punkt 7).
26. „fertig" im Band und in der Filterleiste sind zwei Zahlen. Das Band zählt auf dem Server (154), die Filterleiste die Liste im Schirm (152). Der Unterschied sind doppelte Kennungen in der Ablage — F43 und F44 gibt es je zweimal, und der Schirm führt jede Kennung nur einmal. Gemessen am 22.09.2026; behoben ist es erst, wenn verify:vorhaben eine doppelte Kennung zurückweist.
27. Die Warnzeile der Bahn verliert ihre Blocker an den Filter. Gebaut am 23.09.2026: Planbahn bekommt alle gelesenen Vorgänge als eigene Angabe (bekannte) und bildet „wartet auf" daraus, nicht aus dem Gefilterten. Fertige Karten tragen die Zeile nicht mehr, weil Erledigtes und Verworfenes gar nicht mehr in der Bahn steht (N199) — siehe „Die Bahn" oben. Seit N289 ist die Planbahn nicht mehr eingebunden (Punkt 61).
28. Eine offene Karte bleibt offen, wenn ihr Vorgang aus der Sicht fällt. Gebaut am 23.09.2026 (N130): Sie bleibt weiter offen, sagt es jetzt aber mit Wort und Zeichen und bietet „Sicht zurücksetzen" an — siehe „Die offene Karte bleibt, auch außerhalb der Sicht" oben. Offen bleibt: siehe Punkt 52.
29. Die Tafel verliert mit Filter oder Suche ihre Spalten. Sie zeigt nur Zustände, in denen etwas liegt; gefiltert heißt das: eine Verteilung, die es so nicht gibt. Die Spalten zu halten braucht eine Spaltenfolge als eigene Angabe an Tafel.
30. Am Telefon ist die Filterleiste noch hoch. Gebaut am 23.09.2026 (N190): Die ganze Leiste steht hinter der Pille Filter, und die Wahl steht bei zugeklappter Leiste als Pille neben den Sichten — also nicht gesetzt und unsichtbar. Siehe „Die Filterleiste" oben.
31. Der Erklärtext der Bahn steht noch offen. Gebaut am 23.09.2026 (W15): Er liegt hinter „Wie die Reihenfolge entsteht", demselben Aufklapper wie bei Band und Systemtafel (client/Erklaerung.tsx). Seit N289 ist die Planbahn nicht mehr eingebunden (Punkt 61).
32. Am Telefon fehlt der Wochentrend. — erledigt anders am 10.10.2026: Die Verlaufslinie ist überall entfernt, weil sie zu keiner Handlung führte (ES-261009-kennzahlen-nur, E13).
33. Die Bereichs-Wand kennt „nicht gelesen" nicht. Sie unterscheidet nur lädt und leer und sagt ohne Stand „Kein Bereich trägt einen Vorgang." Der Schirm stellt deshalb ohne Stand seinen eigenen Satz an ihre Stelle; eine Angabe unbekannt an Bereichswand wäre die Stelle, an die das gehört.
34. Die Priorität steht nur an der Wand, nicht in der Bahn. Die Bahn ordnet nach Anheften und Rang des Vorgangs; dass ein Bereich sperrt trägt, hebt seine Vorgänge dort nicht nach vorn. Ob sie es sollte, oder ob die Bahn gerade die Hand-Ordnung gegen die Kategorien ist, ist eine Frage an Christian. Erledigt mit N289 (25.09.2026): Die Bahn ist kein Reiter mehr, die Frage stellt sich auf keinem Schirm.
35. Ein Thema lässt sich nicht verschieben. Es gehört zu genau einem Bereich; wer es unter einem anderen braucht, legt es dort neu an und ordnet die Vorgänge um. Ein Umzug hieße, die Kennung in jeder Datei mitzunehmen, deren Bereich sich dabei nicht ändert.
36. Die Kennung eines Themas bleibt, wie sie entstand. Umbenennen ändert nur den Namen; wer die Kennung ändern will, legt ein neues Thema an und entfernt das alte — dann wandert jede Zuordnung über einen Auftrag an die Dateien.
37. Die Tafel ist nach Wandwahl nicht nach Thema gegliedert (die Bahn ist seit N289 kein Reiter mehr). Bewusst (siehe oben); eine Pille „Thema: …" als Filter wäre der Weg, dort nach Thema zu schauen, und steht noch nicht in der Filterleiste.
38. Die Themenauswahl steht nur in der Bereichsansicht. In der ungefilterten Kachelliste gehören die Kacheln zu vielen Bereichen, jeder mit eigenen Themen; die Zeile fehlt dort, und zuordnen lässt sich ein Vorgang nur nach einem Klick auf seine Wandkachel. Die offene Karte hat die Zeile ebenfalls nicht.
39. Kein Ziehen zwischen Themen. Eine Kachel wandert nur über die Auswahl im Feldsteller in ein anderes Thema. Ziehen wäre schneller — und hätte dieselbe Gefahr wie auf der Tafel.
40. Das Register kennt keine Themen. REGISTER.md gruppiert nach der Gruppe der Ablage und hat nicht einmal eine Spalte für den Bereich; eine Spalte thema zeigte in Hunderten Zeilen einen Strich und dort, wo etwas stünde, nur die Kennung ohne Namen, weil der Name in der Datenbank liegt.
41. Farbe und Zeichen je Bereich fehlen noch. Gebaut am 22.09.2026 (N132): Scheibe auf der Wand, Chip auf Kachel und Karte, beides in der Bereichsfarbe. Der Streifen links an der Wandkachel, der die Farbe des Urteils trug, ist am 10.10.2026 gegangen (ES-261009-farbige-seitenstreifen, E11); die Frage, welche Farbe gewinnt, stellt sich damit nicht mehr.
42. Ein Bereichswechsel nimmt das Thema mit. Gebaut am 23.09.2026 (N132): stelleFeld stellt thema auf -, sobald bereich sich ändert — im selben Zug, über dieselbe Schicht admin.vorgangsaenderungen. Siehe „Ein Bereichswechsel löst das Thema mit" oben. Offen bleibt: siehe Punkt 53.
43. niedrig und keine Priorität sehen im Baum gleich aus. Behoben am 22.09.2026 (N132): Wo „keine" möglich ist, trägt niedrig einen blassen Winkel nach unten (zeigeNiedrig). Weiter behoben am 23.09.2026: Auch Kachel (Kachel.tsx) und Karte (Vorgangskarte.tsx) zeichnen ihn jetzt — dieselbe Stufe sieht dort aus wie überall sonst. Offen bleibt: siehe Punkt 54.
44. Die Filterleiste zeichnet ihre Zeichen noch nicht. Gebaut am 22.09.2026 (N132): Filterknopf kennt ein freiwilliges zeichen, die Leiste setzt es vor das Wort. Offen bleibt: Nur dieser Schirm gibt seinen Werten Zeichen mit; die übrigen Listen mit Feldern zeigen weiter das Wort allein.
45. Der Zustandsring widerspricht dem Guide in der Farbe. §7.4 gibt Fortschrittsringen den Verlauf des „O"; der Ring hier trägt die Zustandsfarben. Er ist ein Zustand und kein Fortschritt — aber das steht im Guide nicht, und er ist als offen notiert.
46. Die Art liest nur den Ordner. Ein Fehler in Bens Liste trägt die Sternschnuppe, ein Fehler, der erledigt ist, den Käfer nur, solange der Server den alten Ordner zurückrechnet. Wer die Art unabhängig vom Ordner will, braucht ein Kopffeld — und damit eine zweite Antwort.
47. „Ideen" als Sicht und „Idee" als Art tragen dieselbe Glühbirne. Die Sicht meint „noch ohne Urteil", die Art „aus der Langfrist-Ablage"; eine beurteilte Idee aus 7-langfrist trägt die Birne und steht nicht unter „Ideen". Beide meinen „noch nicht beschlossen" — ob das reicht, zeigt der Gebrauch.
48. Das Meta-Pult hat eigene Zeichen. Sein Sprite zeichnet Käfer, Schlüssel und Server mit denselben Pfaden, aber ohne Verbindung zur Registry; ein geändertes Zeichen hier ändert es dort nicht.
49. Löschen geht nur einzeln. Wer zehn Vorgänge aufräumen will, klickt zwanzigmal. Eine Auswahl über mehrere Kacheln mit einem Knopf darüber wäre der nächste Schritt — und bräuchte dieselbe Rückfrage, nur mit der Zahl darin.
50. Kein Grund beim Löschen. GELOESCHT.md verlangt einen Satz, warum; der Knopf fragt nicht danach, und ich muss ihn beim Ausführen erschließen. Ein optionales Feld neben ja, weg wäre die Stelle.
51. Projekte lassen sich nur an der Karte löschen, und auch dort sagt nichts, dass die Teile dabei ihren Vater verlieren. Ob sie mit gehen oder oben stehen bleiben, entscheide heute ich beim Ausführen.
52. Die Meldung „außerhalb der Sicht" kennt den Baum nicht. geoeffnetAusserSicht misst gegen gefiltert — dieselbe Menge, die Kacheln und Tafel zeigen. Der Baum liest weiter unverändert gelesen.baum (Punkt 2) und zeigt einen Vorgang oft trotzdem, obwohl Sicht, Filter oder Suche ihn ausschließen würden. Wer eine Karte im Baum öffnet, deren Vorgang etwa durch Sicht „Ideen" gefiltert wäre, sieht die Zeile „liegt außerhalb der aktuellen Sicht" — obwohl der Vorgang im Baum daneben sichtbar bleibt.
53. Nur der Weg über stelleFeld löst das Thema mit. Der Fix vom 23.09.2026 sitzt in admin.vorgangsaenderungen und greift bei /api/verwaltung/stellen und beim MCP-Werkzeug verwaltung_stellen. Wer bereich: stattdessen direkt im Dateikopf ändert, muss thema: weiter von Hand mitändern — die Verwaltung liest beide Felder unverändert aus der Datei, ohne sie gegeneinander zu prüfen.
54. niedrig bleibt an zwei Stellen weiter unsichtbar. Behoben am 23.09.2026: Der einzelne Vorgang im Baum, die Entwurfsliste und die Dringlichkeitsknöpfe im Entwurfsfach tragen jetzt zeigeNiedrig. Jede Stelle, die einen Rang zeichnet, zeigt damit auch niedrig. Probe: „zeigt auch am Knopf ‚niedrig' einen Rang" in Verwaltung.test.tsx.
55. Wer den Bereich zurückdreht, bekommt das Thema nicht zurück. Ein Bereichswechsel schreibt zwei Zeilen: bereich und thema = - (Punkt 42). Stellt man den Bereich danach wieder auf den Wert aus der Datei, verschwindet die Zeile für bereich, die für thema bleibt. Der Vorgang steht dann im alten Bereich ohne sein altes Thema. Beheben ließe sich das, indem das Zurückdrehen eine thema-Zeile mit - gleich mitnimmt. Offen ist, ob das eine bewusst gesetzte Wahl „ohne Thema" überschreiben darf.
56. „bei mir" und „ich" meinen Claude, egal wer hinsieht Gebaut am 23.09.2026 (N182): Christian hat „bei Claude" gewählt — den Namen, nicht ein Wort nach dem Betrachter. Filterleiste und Feldsteller sagen „bei Claude", die Kürzel auf Kachel und Karte „Claude".
57. Die Suche der Einstellungen findet die Verwaltung nicht mehr (A41). Ihr Eintrag „Verwaltung“ ist mit der Kategorie gegangen; wer „Rolle“ oder „Vorgabe“ in die Einstellungssuche tippt, landet nicht im Reiter „Admin“. Die Schnellsuche kennt /admin — für ein Konto nur mit settings.global_default aber nicht, weil sie über bereichslage fragt.
58. Die Knöpfe „für alle“ an einzelnen Einstellungen bleiben in den Einstellungen (A41). Sie setzen eine Vorgabe genau dort, wo man den Wert sieht; in den Reiter gezogen, müsste man die Einstellung dort ein zweites Mal suchen. Ebenso bleibt „Als jemand anderes“ in den Einstellungen, weil es das eigene Arbeiten betrifft.
59. Schritte lassen sich auf dem Schirm nur abhaken. Die Vorgangskarte reicht der Schrittliste nur onHaken durch, nicht onAnlegen, onAendern, onVerschieben und onLoeschen; Feld „Noch ein Schritt …“, Umformulieren, Pfeile und Kreuz erscheinen deshalb nirgends. legeSchrittAn, aendereSchritt, verschiebeSchritt und loescheSchritt in client/anfragen.ts ruft niemand; anlegen, ändern, schieben und streichen geht nur über das MCP-Werkzeug verwaltung_schritt.
60. Vier Gruppen der Instanzwerte tragen keinen Titel. GRUPPENTITEL in Instanzwertpflege.tsx kennt nur Bremsen, Schicht, Modell, Nutzungsprotokoll und Rückfall; die Karten begleiter, tutor, karten und gast zeigen als Kopf den rohen Schlüssel, unübersetzt.
61. Die Planbahn liegt tot im Paket. client/Planbahn.tsx und sein Test werden seit N289 von keinem Schirm eingebunden; Kommentare in Erklaerung.tsx, ziehen.ts und zeichensatz.ts verweisen noch auf sie. Route /api/verwaltung/bahn und verwaltung_bahn bleiben für bestehende Aufrufer — ob die Datei mitgeht, ist offen. Am 10.10.2026 hat ES-261010-restliche-kartenraster auch sie auf Zeilen mit Haarlinien gestellt (die Zustandsschiene N204 bleibt), damit sie nicht als letzter Kartenstapel zurückkommt, falls sie wieder eingebunden wird.
62. Der Leitstand kennt kein Gewicht je Konto. Welches Konto wie viel der parallelen Arbeit trägt, stellt man nur über die Zielzahl der Überschreibung, nicht dauerhaft (B-261014-gewicht-je-konto).
63. Offene Fragen aus Vorgängen lassen sich im Leitstand nicht beantworten. Die Fragen aus den Bahnen schon (seit 15.10.2026); bei einem Vorgang mit liegt-bei: christian oder ben öffnet ein Klick die Vorgangskarte, die Antwort steht dort oder im Repository (B-261013-leitstand-fragen, Schritt 3).
64. Das Protokoll hat keinen Filter. Es zeigt die letzten Zeilen, die der Server schickt, ohne Wahl nach Konto, Art oder Bahn.
65. Gründe des Dienstes kommen deutsch. Freie Gründe und Einzelheiten im Protokoll stehen, wie der Dienst sie schreibt; die englische Oberfläche übersetzt sie nicht.
66. Das Menü „Neu“ zeigt nur Titel. Gebaut am 14.10.2026: Das geteilte Dropdown nimmt je Eintrag eine Zeile unter dem Titel; sie ist die Beschreibung des Eintrags, sein Name bleibt der Titel.
67. Ein Musterbogen sieht unter scharfer CSP anders aus. Der Rahmen erbt die Richtlinie des Leitstands; schaltet B-261012-csp-scharf-schalten script-src 'self' scharf, laufen die eingebetteten Skripte des Bogens nicht mehr, und Schriften von Google fehlen. Text und Gestalt bleiben.
68. Der Verlauf rechnet Zeiten nur so genau wie die Takte. Die Sekunden je Zählung zählen von Takt zu Takt und höchstens fünf Minuten je Lücke; der Verbrauch je Lauf ist der Wochenanstieg, gleich auf die verbrauchenden Sitzungen verteilt, also eine Schätzung. Ein Lauf, der zwischen zwei Takten begann und endete, fehlt (B-261018-leitstand-verlauf).

Verwaltung › Postfächer (E-261021-verwaltung-postfaecher)

Code: client/Postfachpflege.tsx, im Abschnitt „Konten und Zugang“ unter „Postfächer“. Oben stehen drei Zahlen (Postfächer, bereit, brauchen Pflege), darunter ein Kachelraster: je Postfach eine Marke, die Adresse, ein Zustand (grün „Bereit“, gelb „Noch ohne Verwalter“, grau „ohne Passwort“), der Zweck, die Verwalter und die Köpfe der Zugänge. „Zugänge ändern“ öffnet das Freigabefenster; „Postfach anlegen“ öffnet ein Fenster mit Adresse und Zweck. Ein Passwort setzt nur der Meta-Server, der Schirm fragt keines ab. Gestaltet nach dem Musterbogen vom 21.10.2026, Wahl P1 a und P2 a.