/people — Kontakte

Hinweis: Rahmen: 00-rahmen.md. Code: packages/plugins/src/people/ · Nachweise verify:mbti, verify:dev, verify:salon.

Wofür

Der Salon: wer zu Christians Leben gehört, mit dem, was man über sie weiß und wann man zuletzt Kontakt hatte. Dazu ein zweiter, verdeckter Teil — Persönlichkeiten, eine eigene Fähigkeit.

Seit dem 11.10.2026 heißt der Bereich auf dem Schirm Kontakte (F-261011-personen-kontakte, Rückmeldung von type-Ignore): in Leiste, Überschrift, Rechtebaum, Teilexport, Rückblick und Schnellsuche (@). Weg, Merkmal, Kennungen und Tabellen heißen weiter people. Telefon und E-Mail stehen in der Liste gleich hinter dem Namen, wie in einem Adressbuch; beide Felder gab es schon. Mail selbst kommt später (3-bens-semester).

Weg und Rahmen

Was man sieht

Drei Abschnitte: Alle · Dozenten · Persönlichkeiten.

Netz (erste Ansicht, Vorgabe): Personen in Haufen — je Modul einer mit dem Modul in der Mitte, je Runde untereinander Verbundener einer, die Übrigen zusammen; jeder Haufen mit leiser Fläche. Linien zeigen Verbindungen untereinander, Rahmen den Bezug zu mir, je Art mit Farbe und Strich. Die Legende steht oben links im Bild; ohne jede Verbindung sagt sie „0 Verbindungen · Bezug in der Person“. Mausrad, Kneifen und Ziehen zoomen und schieben, unten rechts Näher, Weiter weg, Wieder mittig; Plus, Minus und Null auf der Tastatur.

Der Reiter „Persönlichkeiten" erscheint gar nicht, wenn die Fähigkeit fehlt — nicht ausgegraut, sondern nicht vorhanden. Dasselbe gilt für einzelne Spalten: Felder, für die dem Nutzer die Fähigkeit fehlt, liefert der Server nicht mit, und die Oberfläche baut ihre Spalten aus dem, was ankommt. Eine leere Spalte würde verraten, dass es das Feld gibt.

Spalten Personen: Name · Spitzname · Tätigkeit · Herkunft · Geschlecht · Geburtstag · Alter · Tage bis (zum Geburtstag) · Telefon · E-Mail · Adresse · Beziehung zu · Verbunden von · Erster Kontakt · Letzter Kontakt · Abstand · Letztes Treffen · Seit dem Treffen · Zuletzt zusammen · Wann · Ereignisse · PIN · Endnote.

Die letzten beiden nur, wer die Fähigkeit dafür hat — und dann nicht als leere Spalte, sondern gar nicht.

Zuletzt zusammen ist seit dem 03.10.2026 (NV15, N499) ein Weg zu genau diesem Termin (ANSCHLUESSE.knoten?.event?.weg); der Server gibt dafür last_event_id neben dem Namen aus. In der Standardsicht ist die Spalte ausgeblendet.

Erster Kontakt steht seit dem 22.09.2026 da, vor den beiden anderen Datumsspalten: die drei lesen sich als Zeitstrahl — seit wann, zuletzt gesprochen, zuletzt gesehen. Die Spalte first_contact gibt es seit Migration 3; bis dahin fuhr sie bei jedem Abruf über die Leitung und kam nirgends an.

Beziehung zu und Verbunden von stehen seit dem 22.09.2026 da, und sie sind zwei Seiten derselben Sache. Gespeichert ist eine gerichtete Kante: life.people.relationship_id (Migration 3) zeigt auf eine andere Person. „Beziehung zu" nennt deren Namen und führt mit einem Klick zu ihr (?a=all&id=…); „Verbunden von" nennt alle, die umgekehrt auf diese Zeile zeigen — auch das als Weg dorthin. Die Gegenrichtung ist gerechnet, nicht gespeichert (shared/beziehungen.ts): sie entsteht aus derselben Liste, die der Schirm ohnehin hat. Eine zweite Tabelle dafür wäre genau die eigene Verweistabelle, die Richtung G1 verbietet. Zeigen beide aufeinander, steht derselbe Mensch in beiden Spalten — das ist der sichtbare Unterschied zwischen „ich nenne ihn" und „wir nennen uns". Ein Ziel, das der Abschnitt nicht enthält (im Abschnitt „Dozenten" jeder ohne Häkchen), bleibt leer statt eine Kennung zu zeigen: eine UUID ist kein Name.

„Dozent" und „Persönlichkeit" sind keine Spalten, sondern Felder im Editor (nachgesehen am 21.09.2026: personenAnsichten.ts baut die Tabelle aus COLUMN_ORDER, und beide stehen nicht darin — editFields in Personenmenue.tsx hat sie). Bis heute standen sie hier unter den Spalten, und „Gruppe" dazu; „Gruppe" gehört zu den Persönlichkeiten, nicht zu den Personen.

Abstand und Seit dem Treffen sind gerechnet, nicht gespeichert: „seit 94 Tagen" statt „14.06.2026", mit Farbe nach Stufe — frisch bis 14 Tage, dann grau, ab 60 gelb, ab 180 rot. Wer nie gemeldet hat, bleibt grau: das ist entweder neu oder seit Jahren her, und beides weiß niemand. Gerechnet wird gegen den Tag des Nutzers, nicht des Servers (Grundsatz 54).

Spalten Persönlichkeiten: Typ · Kürzel · Temperament · Intellekt · Freundschaft · Romantik · Anteil · Summe · Bewertungen.

Ansichten: Tabelle · Karten (Brett) · Lange nicht gemeldet · Gesichter. Verlinkbar über ?v=tabelle|karten|lange-nicht|gesichter. Über den Karten und über „Nach Gruppe“ der Persönlichkeiten steht seit dem 30.09.2026 die Ordnungsleiste wie über jedem Brett in Denotato (E02, 00-rahmen.md): sortieren und nach einem Feld in Spalten teilen. Die Karten sind von sich aus ungruppiert und bleiben es, bis jemand ein Feld wählt; gemerkt wird je Ansicht.

Die Gruppen der Persönlichkeiten stehen in Tabelle, Pille und den Spaltenköpfen von „Nach Gruppe“ als Wörter da („Analysten“, „Diplomaten“, „Wächter“, „Entdecker“; englisch „Analysts“ usw.), nicht als Datenbankwert analysts (I08, woerter an der Spalte, persoenlichkeitsAnsichten.test.tsx). Gespeichert, sortiert und gruppiert wird weiter der Rohwert.

Die dritte sortiert nach letztem Kontakt, Lücken zuerst: wer gar keinen Eintrag hat, ist entweder neu oder seit Jahren nicht gemeldet, und beides will man sehen — nicht ganz unten hinter denen von gestern.

Gesichter (seit 21.09.2026) zeichnet jede Person als Kreis mit Initialen, die Farbe aus dem Namen gerechnet — die Philosophie §3.3 sagt „Person → Kreis, Initialen oder Bild, immer rund. Menschen sind keine Kacheln." Unter dem Kreis ein Punkt in der Farbe des Kontaktabstands; was er heißt, sagt der Zeigerhinweis, und der nennt beides — letzten Kontakt und letztes Treffen. Der Editor öffnet unter dem Raster, und im Kopf des Editors stehen seit dem 22.09.2026 dieselben Handgriffe wie an einer Tabellenzeile — „gemeldet", „getroffen", „wegtun".

Oben über allem der Geburtstagshinweis (seit 21.09.2026): wer in den nächsten vierzehn Tagen Geburtstag hat, steht in einer Zeile über der Liste — in jedem Abschnitt und jeder Ansicht, nicht nur in der Tabelle. Derselbe Horizont wie im Briefing, und ein Nachweis hält die beiden Zahlen aneinander. Ein Klick setzt die Suche auf den Namen. Vor der Aufschrift „Geburtstag" steht seit dem 23.09.2026 das Zeichen geburtstag — stumm, das Wort daneben bleibt die Auskunft.

Zeichensprache (N134, seit 23.09.2026). Die drei Abschnitte tragen jetzt ein Zeichen: Alle → person, Dozenten → kappe, Persönlichkeiten → persoenlichkeit. Dieselben vier Ansichten — Tabelle, Karten, Lange nicht gemeldet, Gesichter — tragen tabelle, kacheln, abstand (seit E12, 30.09.2026; bis dahin geliehen zeit, das Bereichszeichen des Stundenplans) und person; die drei Ansichten der Persönlichkeiten tabelle, wichtig (für „Bewertungen" — nicht stern, den der Guide §7.5 für eine Bewertung ausdrücklich verbietet) und tafel. Tabelle trägt seit dem 28.09.2026 das eigene Zeichen tabelle (N406), davor ab dem 23.09.2026 uebersicht und nicht mehr tafel: die bereichsübergreifende Regel gibt „Alle" und „Tabelle" dasselbe Zeichen wie in study und materials, tafel bleibt der gruppierten Brettansicht (Spalten) vorbehalten. Der Punkt unter dem Kreis in „Gesichter" trägt für die Stufen frisch, lange und sehr lange zusätzlich zur Farbe ein Zeichen (frisch, abstand, funkstille — die beiden letzten seit E12, 30.09.2026, zwei Menschen mit einer Linie dazwischen, die bei abstand eine Lücke hat und bei funkstille fast weg ist; bis dahin geliehen faellig und ueberfaellig) — für „länger" und „nie" bleibt er ein reiner Punkt, wie schon die Farbe es tut. Dieselbe Zuordnung färbt seit demselben Tag auch die Spalten „Abstand" und „Seit dem Treffen": das Zeichen steht dort neben dem Wort, nicht statt seiner. Meldet der vCard-Einleser einen Fehler, steht seit demselben Tag das Zeichen warnung vor dem Satz. Seit dem 23.09.2026 trägt nur noch das Zeichen die rote Farbe (theme.colors.status.danger direkt am Zeichen, nicht über currentColor vererbt) — bis dahin färbte dieselbe Regel auch den Satz daneben mit, obwohl das Wort die Auskunft schon selbst nennt (Guide §7.1: das Wort bleibt neutral).

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 people, Ansichten je Abschnitt people/<abschnitt> (Rahmen §3).

Scheitert das Einlesen, bleibt „vCard einlesen (.vcf)" bedienbar (F28b, 23.09.2026): Der Knopf setzt seinen Laufmerker über useBusyLock, das ihn in einem try/finally wieder freigibt, statt bei „Wird eingelesen …" gesperrt stehen zu bleiben, wenn die Datei nicht gelesen werden kann.

Woher die Daten kommen

PEOPLE_LIST · PEOPLE_SAVE · PEOPLE_MELDEN · PERSONALITIES · PERSONALITY_SAVE · PERSONALITY_ASSIGN.

PEOPLE_SAVE lässt beim Ändern stehen, was fehlt — für fünf Felder (F38, 23.09.2026): firstContact, relationshipId, isLecturer, pin und finalGrade; null leert, wo es einen leeren Zustand gibt. Bis dahin nahm ein person_speichern({id, displayName}) einer Dozentin die Marke, und weil das Werkzeug pin gar nicht kennt, leerte jeder seiner Änderungsaufrufe die PIN eines Kontos, das sie sehen darf. Die übrigen Felder (Spitzname bis Adresse) schreibt jeder Aufruf weiterhin vollständig — das Formular schickt sie immer mit. Der Schirm ändert sich dadurch nicht: er schickt „Dozent" als Häkchen stets mit, PIN und Endnote, sobald sie in der Zeile stehen.

Aufgehoben wird unter people.personen und people.persoenlichkeiten (G03, 21.09.2026, Rahmen 7). Über beiden steht eine Marke, und sie nennt den älteren der beiden Stände.

Die Eule: „Auf ein Gespräch vorbereiten“ (KI21, N372)

Die offene Person steht als ?id=<id> in der Adresse (client/gegenstand.ts; unter „Persönlichkeiten“ gibt es keinen Gegenstand). Nach N372 gibt der Leser von ihr nur Nicht-Sensibles mit: Name, Rufname, Beruf, Dozent, Beziehung, erster und letzter Kontakt, letztes Treffen und die gemeinsamen Termine. Telefon, E-Mail, Adresse, Herkunft, Geburtstag, PIN, Note und Persönlichkeit gibt er nie mit; eine fremde oder weggetane Person wird abgewiesen wie ein unbekanntes Angebot. Seit KI36 (N501) darf das Angebot mit den lesenden Werkzeugen des Begleiters nachlesen; personen_liste liefert dabei die Felder, die das Konto selbst sieht, Kontaktdaten und Geburtstag eingeschlossen. Das ist die Lage nach N382, die die Lesegrenze aus N372 für den Begleiter aufgehoben hat; das Menü der Eule verspricht deshalb nicht mehr, sie blieben hier.

Was fehlt

1. Kein „melden"-Weg — die Schnellaktion person.melden öffnet seit dem 17.09.2026 die Ansicht „Lange nicht gemeldet" statt der alphabetischen Liste. Der Kern nennt dabei keinen Bereich beim Namen: er nennt einen Weg und eine Ansichtskennung. Was fehlt: sie öffnet die Liste, nicht die eine Person — der Guide (S12) meint Letzteres.
2. „Letzter Kontakt" lässt sich nicht setzen · last_meetup fehlt — beide Handgriffe stehen seit dem 21.09.2026 an der Zeile: „gemeldet" führt last_contact, „getroffen" führt last_meetup. Der Tag wird von der Oberfläche mitgeschickt, nicht vom Server bestimmt: um 23:30 in Berlin ist es in UTC schon morgen (Grundsatz 54). Über den MCP beides unter person_gemeldet, mit was: "gemeldet"|"getroffen". first_contact fehlt — die dritte Datumsspalte steht seit dem 22.09.2026 in der Tabelle und im Editor, und PEOPLE_SAVE nimmt sie entgegen (firstContact, auch über den MCP). Sie bleibt unerwähnt unverändert — seit dem 22.09.2026 zusammen mit relationshipId das zweite und letzte Feld, für das das gilt: alle anderen werden bei jedem Speichern vollständig geschrieben, und ein neues Feld soll diese Falle nicht erben. Keine Gegenprobe gegen den Geburtstag — seit dem 22.09.2026 prüft der Editor vor dem Speichern die Reihenfolge aller vier Daten (shared/datumsfolge.ts, reine Rechnung, der Tag kommt aus der Zeitschicht): erster Kontakt nicht vor dem Geburtstag, letzter Kontakt und letztes Treffen nicht davor, und keines in der Zukunft. Der Satz nennt, was sich widerspricht, und geschrieben wird dann nichts. Was fehlt: die Probe steht nur im Formular — siehe Punkt 18.
3. Kein Geburtstagshinweis — es gibt ihn seit dem 21.09.2026, über der Liste, in jedem Abschnitt und jeder Ansicht, mit demselben Horizont von vierzehn Tagen wie das Briefing (ein Nachweis hält die beiden Zahlen aneinander). Was noch fehlt: eine Erinnerung, die von selbst kommt. Briefing und Schirm sagen es beide erst, wenn man sie aufruft — wer eine Woche nicht hereinschaut, erfährt den Geburtstag am Tag danach.
4. Keine Farben an Auswahlwerten — das gibt es (geprüft am 17.09.2026). theme/wertfarben.ts rechnet aus dem Wert selbst eine Farbe, personenAnsichten.ts nutzt sie über die Zellenart auswahl. Absichtlich kein Grün und kein Rot: eine Herkunft, die zufällig die Farbe von „überfällig" trägt, wäre eine Auskunft, die niemand gemeint hat. Was wirklich fehlt: dieselbe Farbe im Formular — das SelectField zeigt sie nicht, nur die Tabelle.
5. Kein Kreis — die Ansicht „Gesichter" zeichnet seit dem 21.09.2026 Kreise, Initialen darin, die Farbe aus dem Namen gerechnet (Guide §6, Philosophie §3.3). Was fehlt, ist das Bild: life.people hat keine Spalte dafür, und components/formen/Kreis könnte längst eines zeigen. Solange die Spalte fehlt, sind alle Gesichter Initialen — und zwei Personen mit denselben Initialen sehen sich zum Verwechseln ähnlich.
6. Keine Notizen zu einer Person. Ein Feld für „was ich mir merken will" gibt es nicht — und das ist eine fehlende Spalte, keine fehlende Anzeige: life.people hat weder notes noch etwas Ähnliches (nachgesehen am 21.09.2026 an der laufenden Datenbank). Das fällt seit dem vCard-Import an einer zweiten Stelle auf: der Einleser liest das Notizfeld einer Karte und wirft es weg, weil es keinen ehrlichen Ort dafür gibt (shared/vcard.ts sagt das im Kommentar, und ein Nachweis hält fest, dass die Notiz nicht heimlich in ein anderes Feld rutscht). Wer das baut, braucht zuerst eine Migration.
7. Keine Beziehungen untereinander · keine Spalte · kein Feld · keine Gegenrichtung — seit dem 22.09.2026 ist die Kante sichtbar und setzbar: zwei Spalten („Beziehung zu", „Verbunden von"), beide als Weg zur Person, eine Auswahl im Editor, und PEOPLE_SAVE nimmt relationshipId entgegen (auch über den MCP). Wie firstContact bleibt sie unerwähnt unverändert; null löst sie. Eine Kennung, die nicht zu diesem Konto gehört, gilt als nicht vorhanden (Grundsatz 22 — von außen sieht sie aus wie keine); die eigene Kennung wird verworfen und steht in ignoredFields. Die Gegenrichtung ist gerechnet, nicht gespeichert — keine eigene Verweistabelle (G1). Was fehlt: (a) die Kante hat keine Art — es steht nirgends, wer das ist: Mutter, Mitbewohner, Chef. Dafür bräuchte es eine Spalte und also eine Migration. (b) Eine Kante je Person, nicht mehr: wer Geschwister und einen Partner hat, kann nur eines davon nennen. (c) Zeigt die Kante auf jemanden im Papierkorb, bleibt die Spalte leer, ohne zu sagen, warum — gelöst wird sie nicht, aber gezeigt auch nicht.
8. Kein Löschen. — seit dem 19.09.2026 gibt es „wegtun" (B07, Q01): zwei Klicks an der Zeile, dreißig Tage im Papierkorb, danach endgültig. Seit dem 22.09.2026 sagt der zweite Klick auch, wie viele Ereignisse stehen bleiben — gemessen an ARTEN.person im Papierkorb, das keine Nachfahren hat. Was noch fehlt: mehrere Personen auf einmal — dreißig Karteileichen aus einem Import sind dreißigmal zwei Klicks.
9. Keine Verknüpfung zu Terminen — „Zoë hat Geburtstag" steht sehr wohl in einem Kalender: calendarCollector.ts baut aus jedem hinterlegten Geburtstag einen jährlichen Ganztagstermin, mit Ausweichregel für den 29. Februar, im Kalender „GOLD · Geburtstage". Was fehlt, ist die Gegenrichtung: an einer Person steht nicht, welche Termine sie betreffen. Ein Ereignis kennt keine Teilnehmer, und hier gibt es keine Liste „was mit Zoë ansteht".
10. Kein Import · keine vCard · kein Abgleich · kein Weg hinaus — der Einleser steht seit dem 21.09.2026 im Anlegefach, gleicht seit dem 22.09.2026 gegen den Bestand ab (E-Mail, Telefonnummer über die letzten acht Ziffern, Name — in dieser Reihenfolge), und daneben steht seit demselben Tag „vCard schreiben". Ein Nachweis führt den Umlauf: was geschrieben wurde, wird wieder eingelesen und muss dasselbe ergeben — daran fiel auch ein falsch maskiertes Semikolon auf, das eine Adresse in zwei Felder zerlegt hätte. Was fehlt: (a) kein CardDAV, also kein Abgleich, der von selbst läuft; (b) der Abgleich verschmilzt nicht — wer schon dasteht, wird übersprungen, auch wenn die Karte eine Telefonnummer mitbringt, die in Denotato fehlt; (c) ein gleicher Name zählt als bekannt, und zwei verschiedene Menschen mit demselben Namen kommen nur einmal an.
11. Der Kontaktabstand ist nicht sichtbar — er steht seit dem 21.09.2026 an der Zeile, als Wort und als Farbe, für Kontakt und Treffen, und in „Gesichter" als Punkt unter dem Kreis. Was fehlt: die Stufen sind fest verdrahtet (14 · 60 · 180 Tage in shared/kontaktabstand.ts). Wen man wöchentlich spricht, ist nach drei Wochen überfällig; eine Großtante nach zwei Jahren nicht. Ein Rhythmus je Person gibt es nicht, und ohne ihn ist die Farbe für die halbe Liste die falsche.
12. Dozenten sind nur ein Häkchen — ein Modul nennt seinen Dozenten: study.modules.lecturer_id gibt es, das Modulformular hat ein Feld dafür, und die Modultabelle verweist von dort auf die Zeile hier. Was fehlt: Sprechstunde und Raum — dafür gibt es keine Spalte — und die Gegenrichtung: an einem Dozenten steht nicht, welche Module er hält. Moodle weiß es und wird nicht gefragt.
13. Der Rückfall endet am Schirmrand. Personen und Persönlichkeiten bleiben stehen, wenn der Server schweigt; anlegen und ändern geht in dieser Zeit nicht und sagt auch nicht, dass es später ginge (G03, Rahmen 7).
14. Die Handgriffe fehlen in „Gesichter" und auf den Karten. — zweierlei, und nur das eine stimmte (nachgemessen am 22.09.2026): DataView reicht rowAction als cardAction an DataBoard weiter, und das zeichnet sie auf jede Karte — die Karten hatten die Handgriffe also längst. „Gesichter" hatte sie nicht; seit dem 22.09.2026 stehen sie im Kopf des Editors, aus derselben Funktion wie an der Tabellenzeile, und ein Nachweis hält fest, dass beide Ansichten dieselbe benutzen. Was fehlt: im Raster selbst gibt es sie nicht — man muss erst ein Gesicht anklicken. Ein Handgriff am Kreis würde den Kreis zur Kachel machen, also braucht das eine eigene Form.
15. Der Nachweis verify:salon hängt in keiner Kette. — er hängt darin (nachgesehen am 22.09.2026): packages/backend/package.json kennt verify:salon, und verify:kette ruft ihn auf. Er prüft den Kontaktabstand, den vCard-Leser und -Schreiber im Umlauf, den Abgleich beim Einlesen, die beiden Kontaktarten und ein Dutzend Zusicherungen am Quelltext — seit dem 22.09.2026 dazu die Kanten zwischen Personen und die Reihenfolge der vier Daten, 107 Proben. Was fehlt: er kommt ohne Server aus und prüft deshalb nur Quelltext, wo er Verhalten prüfen könnte — dass firstContact und relationshipId unerwähnt unverändert bleiben, dass entfernen eine Spalte leert und dass eine fremde relationshipId abgewiesen wird, steht in keinem Nachweis, sondern wurde am 22.09.2026 von Hand gegen die laufende API gemessen (zwölf Proben am Vormittag, elf am Nachmittag, alle grün).
16. Zwei Verfahren für dieselbe Spalte. — seit dem 22.09.2026 stehen „Letzter Kontakt" und „Letztes Treffen" als Datumsfelder im Editor, und sie gehen über denselben Endpunkt wie die Knöpfe an der Zeile: PEOPLE_MELDEN nahm von Anfang an jedes Datum, nur rief es niemand so. entfernen: true leert eine Spalte wieder — wer sich verklickt hatte, konnte das Datum bisher nur verschieben. Was fehlt: ein Verlauf. Gespeichert wird immer nur das letzte Mal; dass man jemanden im Mai dreimal und seither gar nicht gesprochen hat, steht nirgends, und „seit 94 Tagen" ist dieselbe Zahl für einen alten Freund wie für einen Fremden.
17. „Verbunden von" lässt sich nicht durchsuchen. Die Suche geht über die Zellwerte, und diese Zelle hält eine Liste — sie landet als [object Object] in der Suche (dieselbe Stelle in applyView, die auch life/client/ansichten.ts trifft; es ist kein Fehler dieses Schirms, sondern eine fehlende Regel für die Zellart links). Wer „wer ist mit Anna verbunden" tippt, findet sie nicht über die Gegenrichtung, sondern nur, wenn er Annas Zeile aufschlägt.
18. Die Gegenprobe der Daten steht nur im Formular. PEOPLE_SAVE und das Werkzeug person_speichern nehmen jede Reihenfolge an: ein Modell, das über den MCP einen ersten Kontakt vor dem Geburtstag schreibt, wird nicht aufgehalten. Die Rechnung liegt bereits serverseitig lesbar in shared/datumsfolge.ts (Grundsatz 59) — was fehlt, ist der Aufruf und eine Meldung, die der Endpunkt zurückgeben darf, ohne dafür einen neuen DisplayMessage-Schlüssel in packages/shared zu brauchen.
19. Die Tabellen-Ansicht trug das Zeichen der Brettform. — seit dem 23.09.2026 trägt sie uebersicht (N134, bereichsübergreifende Regel: „Alle" und „Tabelle" tragen uebersicht, wie in study und materials). tafel stand nur so lange dafür ein, wie die Registry kein eigenes Zeichen für eine Reihen-Tabelle hatte, und war ohnehin für Kanban-Spalten gedacht. Das eigene Zeichen tabelle gibt es seit dem 28.09.2026 (N406); es trägt jetzt jede Reihen-Tabelle.
20. „Bewertungen" (Persönlichkeiten) hat kein eigenes Zeichen. — mit Absicht so, geklärt am 30.09.2026 (E12): wichtig (die Fahne) bleibt. Ein eigenes bewertung wurde nicht gezeichnet — eine Note, die nicht wie ein Stern aussieht, wäre entweder eine Zahl (und damit Schrift, kein Zeichen) oder eine zweite Fahne; wichtig trifft, was die Ansicht zeigt: welche Persönlichkeit wie viel zählt. stern bleibt verboten (Guide §7.5).
21. GROUP_TONES (Persönlichkeitsgruppen) nutzt Zustandstoene. progress/done/warn/neutral für vier gleichrangige Gruppen — keine ist „erledigt" oder „in Arbeit". Die Spalte zeigt daneben immer das Wort, „Farbe allein" trifft also nicht zu; trotzdem wäre eine eigene, nicht zustandsbehaftete Tonfamilie der treffendere Ausdruck. Nur festgestellt am 23.09.2026, nicht geändert.
22. Die Kontaktstufe leiht sich faellig/ueberfaellig von einer Fälligkeit, die es hier nicht gibt. — behoben am 30.09.2026 (E12): Das eigene Zeichenpaar für Kontaktnähe ist gezeichnet, abstand für „lange" und funkstille für „sehr lange"; die Ansicht „Lange nicht gemeldet" trägt abstand statt des geliehenen zeit. Der alte Befund: Personen haben kein Datum, das „fällig" wird — nur einen Abstand seit dem letzten Kontakt.