main
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
14d6f5000c |
Der Titel heisst wieder "Zentrale" -- und gehoert jetzt der Adresse
Filipe: "anstatt irrenanstalt soll da auch Zentrale stehen bitte. auch
getrennt von der team dogi seite da steht was anderes und soll auch so
bleiben."
NACHGEMESSEN, BEVOR ETWAS GEAENDERT WURDE -- und es stand NICHT etwas
anderes. `crewWeiche` biegt fuer das Teamhaus sechs Dinge um (Manifest,
App-Symbole, Zugangswand, Buehnen, Marke, Haus-CSS); `start.html` ist
nicht dabei, und kein Skript hat `#ztitel` je angefasst. Auf BEIDEN
Adressen stand seit dem 22.09.2026 derselbe fest eingebaute Titel.
Verschieden war nur die Zierzeile darueber -- "Spicy Media" gegen
"Team Dogi" --, und die hat vermutlich den Eindruck gemacht.
WAS JETZT GILT
* In start.html steht "Zentrale". Das ist die Vorgabe und gilt fuer
das Agenturhaus.
* Das Wort des Teamhauses kommt vom Server (`titelFuer`, direkt neben
`markeFuer`, nach demselben Muster). Dort bleibt damit woertlich
stehen, was vorher dastand -- ab dem 24.09. wird jeder Umbau je
Haus getrennt gefuehrt, und dies ist der des Agenturhauses. Ob
Filipe dort etwas anderes will, entscheidet er; geraten wird es
nicht.
NACH DER ADRESSE UND NICHT NACH DER ROLLE, anders als bei der Marke:
Ein Titel sagt, WO man ist, eine Marke sagt, zu WEM man gehoert. Auch
der Sicht-Umschalter aendert ihn nicht -- wer eine fremde Sicht oeffnet,
wechselt die Zahlen, nicht das Haus.
UND ER STEHT NICHT MEHR IN EINER DATEI, DIE JEDER HERUNTERLAEDT.
Derselbe Grund wie bei MODI_MARKE zwei Zeilen darueber: Was nur das
Teamhaus angeht, gehoert nicht in start.html, die jeder Creator beim
Oeffnen bekommt. Die Schreibweise mit grossem A in der Mitte ist
weiterhin so gewollt und steht jetzt in workspace.js.
GEMESSEN
* pruef-haus-trennung 97 -> 100 Pruefungen, 0 Fehler. Die drei neuen
verlangen den UNTERSCHIED, nicht den Wortlaut: auf crew. ein
eigener Titel vom Server, auf workspace. keiner (dort gilt die
Seite), und die Zierzeilen sind ebenfalls verschieden. Ein
Vergleich mit "Zentrale" waere beim naechsten Umbenennen rot, ohne
dass etwas kaputt ist -- diese Sorte Fehlalarm hatte ich heute
schon einmal.
* pruef-start-ansicht 157, pruef-deutsche-texte 12 -- unveraendert.
* Angesehen bei 1280 px und 390 px: "◆ SPICY MEDIA ◆" darueber,
"Zentrale" darunter.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
9863645952 |
Die zwei Häuser sind getrennt -- und die Tür geht in beide Richtungen
Filipe: "ich will dass du zuerst die komplette site vn der workspace
seite trennst. da soll nichts verknüpft sein. wenn ich bei der einen
was mache soll nichts bei der anderen passieren. … es soll nur für
dogfather eine kachel geben wo er mit einem einfachen klick von der
einen auf die anderen seite kommt aber sonst garnichts."
Das kehrt die Entscheidung vom 10.09.2026 um ("getrennt wird das
AUSSEHEN, nicht der Bestand"). Wer den alten Kommentar liest, liest
einen überholten Stand -- das steht jetzt an jeder betroffenen Stelle.
WAS GEMESSEN WAR, BEVOR ETWAS GEBAUT WURDE
* Nur drei Module trennten nach Haus (Aufgaben, Bereiche, Dateien).
Chat, Kalender, Wissen, Material, Personenlisten und der Rest nicht.
* Die Trennung war EINSEITIG: nurHaus() griff nur auf crew.
* siehtModis() hebelte sie für DogFather auf der Agenturseite aus --
in seiner Gesprächsliste standen dort beide Häuser nebeneinander.
* Keine haus-Spalte in der Datenbank.
* Der Bestand kreuzte aber kaum: 0 von 86 Terminen gemischt, 0 von 7
Zweier-/Gruppengesprächen, genau EIN Kanal.
WAS JETZT DASTEHT
* Drei Rollenmengen in crew-adresse.js (crew / agentur / beide) und
hausVonRolle(); eine unbekannte Rolle bekommt null, kein Haus.
* Spalte `haus` an acht Wurzeltabellen, nachgetragen aus Belegen:
238 Zeilen eindeutig, die Wissensablage geschlossen der Agentur,
vier Restzeilen namentlich, der gemischte Kanal aufgelöst
(die zwei Scouts gehen heraus, die 7 Nachrichten sind alle vom
Team). Offen bleiben: null.
* nurHaus, hausBedingung und darfAnlegen gelten in BEIDE Richtungen.
* Der siehtModis-Durchgriff ist weg -- aber in DREI Fällen, nicht
zwei: Prüfadressen bekommen gar kein Haus und verhalten sich exakt
wie vorher. Die erste Fassung hatte das übersehen und 19 Prüfungen
umgeworfen, an denen nichts kaputt war.
* Kalender: getrennt, aber "belegt" bleibt (Filipes Entscheidung).
Die Blöcke tragen NUR Beginn und Dauer -- kein Titel, keine Person.
Gebaut als Gegenstück zur Liste (meine Termine MINUS die sichtbaren),
damit beide nicht auseinanderlaufen können.
* Die Wissens-Kachel ist auf der Team-Adresse weg UND die Route
antwortet dort mit 404 -- eine fehlende Kachel ist nur eine Bitte.
* Die Wechsel-Kachel für DogFather geht jetzt in beide Richtungen.
GEPRÜFT: pruef-haus-trennung 97 statt 81, 0 Fehler (vorher 7, alle
haben die alte Regel behauptet). Die neuen Abschnitte sind DORT
eingezogen statt in eine zweite Datei -- `pruef-haustrennung.mjs` hätte
sich von `pruef-haus-trennung.mjs` um einen Bindestrich unterschieden.
Dazu grün: haus-seiten, crew-adresse, chat, chat-kanaele,
kanal-besetzung, kalender, serien, treffchat, wissen-neu,
modi-checkliste, modi-katalog, rechtetafel, personen-liste, sicht,
verborgen, fremde-sicht, alle-wege.
NICHT VON MIR: pruef-treff (3) und pruef-kachel-universum (2) waren
schon vorher rot -- beim Treff auf dem Stand
|
||
|
|
82335c783d |
Die rechte Hand legt selbst Personen an -- und sieht die Codes
Filipe: "dan will ich dass die rechte hand auch neue personen hinzufuegen kann. also neue erstellen kann und die codes genau so sieht wie dogfather, damit sie das auch machen kann wenn er live ist." WAS SIE DARF: Modis und Community anlegen, und deren Codes neu setzen. Die Liste ist ABGELEITET aus ROLLEN_ZUM_AENDERN -- dieselben zwei Rollen, die sie ohnehin vergeben darf. Zwei Listen waeren zwei Gelegenheiten, eine davon zu aendern und die andere zu vergessen. WAS SIE NICHT DARF: eine zweite rechte Hand, eine linke Hand oder einen zweiten DogFather anlegen -- und an einer linken Hand auch nichts aendern. Ohne die zweite Schranke haette sie den Code einer linken Hand neu setzen koennen und damit einen Zugang in der Hand, der fast so viel darf wie sie selbst. Die alte Schranke kannte nur "admin" und "manager". NUR DIE RECHTE, NICHT DIE LINKE. `istHand()` haette beide getroffen; fuer die linke Hand ist "legt niemanden an" eine ausdrueckliche Entscheidung vom 21.09. VIER STELLEN IN DER OBERFLAECHE, die alle an Rollennamen hingen: `nurLesen = ich.rolle === 'hand'` -- sie bekam die Liste und kein Formular. Jetzt abgeleitet aus `darf_anlegen`. Die Wache darueber warf sie auf die Startseite, sobald `nurLesen` falsch wurde. Die Seite ging fuer sie einfach nicht auf, ohne Meldung. Der Sendeweg hing an `ich.rolle === 'admin'`. Fuer sie gab es damit GAR KEINEN: Die Seite antwortete "Fuer die Rolle modi gibt es hier keinen Weg" -- ein Satz, der wie ein Formularfehler klingt und eine fehlende Zeile war. UND EIN ECHTER FUND: `rollenwahlErgaenzen()` hing jede Zusatzrolle an das Formular, die mit der Personenliste kam -- ohne zu fragen, ob man sie anlegen darf. Solange nur DogFather das Formular sah, fiel es nicht auf: Er darf sie alle. Der rechten Hand bot es "rechte Hand" und "linke Hand" an. Der Server haette es abgelehnt -- aber der Knopf verriet eine Rolle, die sie nicht vergeben soll. Zwei Pruefungen waren dabei selbst kaputt: pruef-personen-formular erwartete sieben Rollen (seit "linke" am 21.09. sind es acht) und suchte den Namen im sichtbaren Text -- die Abschnitte sind zugeklappt und zeigen nur Anfangsbuchstaben. Beides abgeleitet statt gezaehlt. Geprueft: pruef-personen-formular 43/0 (war 34 ok / 2 FEHL), davon neun am echten Bildschirm auf der Crew-Adresse -- anmelden, Formular oeffnen, anlegen, Code lesen, Person in der Liste wiederfinden. pruef-haus-trennung 81/0 (war 72 ok / 2 FEHL), pruef-rollen-anlegen 11/0. |
||
|
|
8a214ecd0e |
Keine Mischung mehr -- Team Dogi nur noch bei Team Dogi
Filipe: "ich will dass du im workspace alles von team dogi weg nimmst.
nur was ich im kalender eintrage soll ich im workspace sehen und im
team dogi. aber die kacheln von team dogi soll ich nur bei team dogi
sehen und die von workspace nur bei workspace bitte. ich will keine
mischung mehr von kacheln. wie gesagt nur die der kalender soll
verbunden sein von dogfather sonst nichts."
GEMESSEN, WIE SCHLIMM ES WAR: Auf der Agenturadresse bekam DogFather
0 eigene Kacheln ueber die Schnittstelle und 17 fremde -- Dein Team,
Ideen-Board, Rueckmeldung, Wer sieht was, Entwicklung, Werdegang,
Talente und den ganzen Treff samt Moderation. Zwei Betriebe auf einer
Seite.
Das Bittere daran: Dieselbe Datei hatte den Fehler fuer die ANDERE
Richtung am 10.09. schon erkannt und behoben ("Fuenfundzwanzig
Kacheln, von denen zwei Drittel Creator, Scouts und Agentur betreffen,
waeren dort Fenster in ein Haus, in dem er gerade nicht ist"). Nur
andersherum stand es weiter so.
DIE AUSNAHME BRAUCHTE NICHTS: Nachgemessen filtern die Terminabfragen
in workspace-kalender.js NICHT nach Haus. Was er eintraegt, steht
ohnehin auf beiden Adressen. Die Verbindung, die er will, existierte
schon -- sie musste nur nicht zerschnitten werden.
STATT SIEBZEHN BRETTERN STEHT DORT EINE TUER. Ohne sie waere von der
Agenturadresse aus kein Weg mehr zu Team Dogi sichtbar; er muesste die
Adresse tippen. Das ist die Sorte Sackgasse, die dieses Haus nicht
baut. Eine Tuer ist keine Mischung: Sie zeigt kein Brett, sie geht
hinueber. Und sie kommt vom Server, nur fuer `admin` -- in keiner
ausgelieferten Datei steht sie.
MEIN ERSTER ENTWURF GAB SIE AUCH DER RECHTEN HAND UND DER MODERATION.
pruef-modi-checkliste hat es sofort gemeldet: "Modi bekommt 1
Zusatzkachel(n), erwartet keine". Wer NUR zu Team Dogi gehoert, hat
auf der Agenturadresse nichts zu suchen -- die Tuer waere dort seine
einzige Kachel gewesen, also eine Seite, die aus nichts als einem
Ausgang besteht.
VIER PRUEFUNGEN VERLANGTEN DANACH DIE ALTE WELT. Keine davon war ein
Mangel; alle vier haben am falschen Ort gesucht:
pruef-haus-trennung verlangte woertlich, dass die Team-Kachel AUCH
auf der Agenturadresse steht. Sie prueft jetzt die Trennung in
beide Richtungen -- kein Brett von Team Dogi drueben, aber die
eine Tuer -- und leitet die Namen aus der Antwort von crew. ab,
statt sie abzuschreiben.
pruef-start-ansicht zaehlte acht Gruppennamen in fester
Reihenfolge. Gemeint war eine Ordnung ("die Community steht ganz
unten, denn dort stehen Namen und Saetze von Zuschauern"), und
die wird jetzt als Regel geprueft -- bedingt, mit drittem Ausgang
auf Adressen, wo es diese Gruppen gar nicht gibt.
pruef-treff und pruef-rueckmeldung fragten ueber die Agenturadresse
nach Brettern, die dort nicht mehr stehen. Sie fragen jetzt dort,
wo diese Bretter zuhause sind.
EINE HALBE STUNDE WAERE DABEI FAST VERLOREN GEGANGEN: `fetch` kann den
Host-Kopf nicht setzen -- er ist ein verbotener Kopfzeilenname und
wird STILLSCHWEIGEND verworfen. Die Anmeldung ueber die Crew-Wand
genuegt nicht; jede einzelne Abfrage braucht die Adresse. Deshalb geht
die Messung jetzt ueber http.request, so wie es `anmelden()` in
derselben Datei laengst tut.
pruef-haus-trennung 74/0 · pruef-modi-checkliste 75/0 · pruef-treff
72/0 · pruef-rueckmeldung 30/0 · pruef-start-ansicht 153/0 ·
pruef-haus-seiten 34/0 · pruef-entwicklung 46/0 · pruef-befinden
113/0 · pruef-rechte-umstellen 46/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
67a0eb8717 |
DogFather konnte einen zweiten DogFather nicht mehr herabstufen
Gefunden beim Durchsehen der schnellen Pruefungen: pruef-haus-trennung stand auf 60 ok / 6 Fehler. Drei Ursachen, eine davon ein echter Rueckschritt von gestern. --- 1. DER RUECKSCHRITT --------------------------------------------- In darfRolleAendern stand seit gestern: if (person.rolle === "admin") return ziel.rolle !== "admin"; Das macht aus "DogFather ist nicht mehr VERGEBBAR" ein "an einem DogFather ist nichts mehr zu aendern". Ein zweiter Zugang liess sich damit nie wieder zuruecksetzen -- er waere fuer immer DogFather geblieben. Die Pruefung sagte es woertlich: "solange es zwei gibt, darf einer wechseln (403)". Die beiden echten Gefahren haengen woanders und bleiben unberuehrt: Niemand KANN 'admin' vergeben, und der LETZTE DogFather laesst sich nicht herabstufen. --- 2. ZWEI SCHLOESSER FUER DIESELBE TUER --------------------------- Ich hatte gestern `rollenZumAendern` mit 403 VOR die vorhandene Pruefung gesetzt, die mit 400 "Unbekannte Rolle." antwortet. Damit war die Luecke wieder offen, vor der der Kommentar vom 17.09. direkt daneben warnt: Zwei verschiedene Antworten -- "gibt es nicht" gegen "darfst du nicht" -- verraten beim Durchprobieren, WELCHE Rollen existieren. Jetzt eine Regel an einer Stelle. `darfAnlegen` ist dort raus, weil Vergeben und Anlegen seit gestern verschiedene Dinge sind. Gemessen: admin anlegen = aendern (sieben Rollen) spicy anlegen = aendern (vier) hand anlegen = — aendern = modi, gast manager anlegen = creator aendern = — Und die eigene Zeile bekommt jetzt 400 mit einem Satz statt 403: Es ist keine Rechtefrage, sondern eine unsinnige Bitte. --- 3. DREI ERWARTUNGEN, DIE AELTER WAREN ALS DIE REGEL -------------- Die Pruefung verlangte 403, wo seit dem 17.09. 400 richtig ist -- ihre Zeile stammt vom 10.09., sieben Tage aelter als die Regel. Und sie verlangte 404 fuer "die rechte Hand vergibt keine Rolle", was bis vorgestern stimmte. Dabei fiel auf, dass NICHTS geprueft hat, ob die rechte Hand ihre neue Faehigkeit ueberhaupt ausueben kann -- nur, dass sie es nicht darf. Eine Pruefung, die nur das Verbotene misst, laesst offen, ob das Erlaubte geht. Jetzt beide Richtungen: an einer anderen rechten Hand aendert sie nichts (403) und an DogFather erst recht nicht (403) einen Modi macht sie sehr wohl zur Community (200) und es steht so in der Datenbank (gast) eine zweite rechte Hand ernennt sie nicht (400) Nebenbei: `unbekannte_kachel` (gestern eingefuehrt) hatte keinen Satz in meldung.js -- die Kennung waere woertlich auf dem Bildschirm gelandet. pruef-meldungen hatte es gemeldet. Und ein Absturz beim Bauen: `const anlegen = await hole(...)` weiter unten im selben Block verdeckt die gleichnamige Funktion im GANZEN Block, auch oberhalb seiner eigenen Zeile. pruef-haus-trennung: 70 ok, 0 Fehler (vorher 60/6). Dazu gruen: rollen-anlegen 11/0, personen-loeschen 40/0, rechte-umstellen 46/0, verteilen 11/0, meldungen 8/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
6e46a08543 |
Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.
Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.
Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.
--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------
1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
Muster: "([^"]*4231[^"]*)". Das hielt
{ host: "127.0.0.1", port: 4231, path: "/404.html" }
fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
einer schliessenden Anfuehrung unterscheiden. Heraus kam
{ host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }
also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
39/0 vorher, 38/1 nachher.
Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.
2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
zweite Durchgang importierte den ersten, um seine Mechanik zu
benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
zweimal.
--- WAS DAS DAUERHAFT HAELT -----------------------------------------
pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.
Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.
--- NACHGEMESSEN ----------------------------------------------------
Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):
crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
push-ziel 10/0 · portnummern 8/0
Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
0207b05da6 |
Die Rechte Hand steht ueber den Modis -- sortiert statt geschrieben
Filipe, mit dem Bildschirmfoto: "rechte hand soll immer ueber modi stehen bitte." DIE REIHENFOLGE STAND AN ZWEI STELLEN, und die zweite war falsch herum: ROLLEN_REIHE hatte die Rechte Hand laengst vor den Modis (und die SQL-Sortierung leitet sich daraus ab) -- aber `zusatzrollen` in workspace-personen.js schrieb sie von Hand, und dort kam Modi zuerst. Genau diese Liste baut die Abschnitte auf der Personenseite und die zusaetzlichen Knoepfe im Anlegen-Formular. Das ist an diesem Tag das VIERTE Mal dieselbe Sache: eine Aussage, zwei Listen, und die zweite ist die, die abweicht. Vorher: der Zeitraum-Schutz (an einer von drei Stellen), die Dauer-Einheit (dieselbe), das Recht zum Aufloesen (Liste kannte es, Nachrichtenweg nicht). Deshalb wird jetzt SORTIERT und nicht geschrieben: Die Liste geht durch ROLLEN_REIHE. Wer die Reihenfolge aendern will, aendert sie dort -- und alles andere zieht nach, statt nachgezogen werden zu muessen. Was in ROLLEN_REIHE nicht vorkommt (heute "gast"/Community), wandert ans Ende statt stillschweigend nach vorn. pruef-haus-trennung 63 -> 66. GEPRUEFT WIRD DIE REIHENFOLGE, NICHT DIE ANWESENHEIT: "beide sind da" waere auch dann gruen gewesen, wenn sie vertauscht sind -- und genau das war der Fall. Dazu eine Zeile, die nachweist, dass die Reihenfolge wirklich aus ROLLEN_REIHE kommt und nicht nur zufaellig stimmt; sonst haette jemand sie auch von Hand andersherum schreiben koennen: richtig im Ergebnis, falsch im Aufbau, und beim naechsten Mal wieder auseinander. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
e3aeeb01cd |
Rollen wechseln: auch Spicy Media -- und DogFather ist nicht mehr vergebbar
Filipe: "ich will dass die rolle spicy und dogfather, auch die rollen
wechseln koennen wenn die personen schon drin sind. von alle
kategorien, creator, scouts, manager spicy. dogfather soll man nicht
auswaehlen koennen. das ist die einzige die man nicht auswaehlen kann
bitte."
ZWEI AENDERUNGEN, BEIDE IN EINER LISTE (ANLEGBAR):
admin: alles AUSSER der eigenen Rolle
spicy: spicy, manager, scout, creator (vorher ohne spicy)
Weil die Oberflaeche ihre Knoepfe aus derselben Auskunft baut
(`darf_anlegen` in /api/ich), verschwindet DogFather damit von selbst
aus JEDER Auswahl -- beim Anlegen wie beim Wechseln, bei Spicy Media
wie bei DogFather. Eine Liste, zwei Formulare, kein Nachziehen.
WAS DAS BEDEUTET, damit es niemand spaeter sucht: Es laesst sich kein
zweiter DogFather-Zugang mehr anlegen und niemand mehr zu einem
befoerdern. Der bestehende ist durch Sicherung 3 geschuetzt (nie den
letzten herabstufen) und kann nicht versehentlich verschwinden.
Zurueckdrehen laesst sich das nur in ANLEGBAR.
DIE TUER: /verwaltung haengt an nurAdmin, und dort steht jetzt eine
DRITTE enge Ausnahme -- PUT auf genau /personen/<Ziffern>/rolle, fuer
genau die Rollen aus darfRollenWechseln(). Gleiche Bauweise wie die
beiden davor (Liste fuer Spicy Media, Liste fuer die rechte Hand). Was
NICHT mitgeht: Codes, Sperren, Loeschen, Zuteilung, Protokoll.
EINE NEUE SICHERUNG, weil sich die Tuer geoeffnet hat: An einer
DogFather-Zeile aendert nur DogFather. Die bestehenden Pruefungen sehen
auf die ZIEL-Rolle ("darfst du 'manager' vergeben?") -- dass die
BETROFFENE Person DogFather ist, kam darin bis heute nicht vor.
Sicherung 3 haette es heute zufaellig abgefangen, weil es genau einen
gibt; eine Sperre, die nur wegen einer Zahl im Bestand haelt, ist
keine.
DIE OBERFLAECHE: "Rolle aendern" und "Loeschen" hingen an EINER Zeile
(`ich.rolle === 'admin'`). Sie gehoeren nicht zusammen -- Loeschen
bleibt bei DogFather. Und die CSS-Regel, die fuer Spicy Media die ganze
Knopfreihe ausblendete, ist weg: Welche Knoepfe es gibt, entscheidet
jetzt personen.js, und was nicht entsteht, muss man nicht verstecken.
pruef-spicy 62 -> 83. Gemessen wird jede der vier Kategorien EINZELN
(waere nur eine offen, saehe "geht" genauso aus), dazu: admin weder von
Spicy Media noch von DogFather vergebbar, an DogFathers Zeile aendert
sie nichts (und er ist danach nachweislich noch admin), ein Manager
kommt an den Weg nicht, loeschen bleibt zu -- und im Browser, dass der
KNOPF da ist, nicht nur das Recht. Genau daran war heute frueh im Chat
eine Stunde draufgegangen.
Dabei zwei eigene Messfehler gefunden: Die Knoepfe entstehen erst in
einer AUFGEKLAPPTEN Kategorie (vorher zu frueh gemessen), und /api/ich
wird jetzt als Vorbedingung geprueft.
DREI PRUEFUNGEN GEDREHT, KEINE GELOESCHT:
- pruef-personen-formular: 7 Karten, `admin` fehlt (eigene Aussage).
Die Zeichenpruefung verglich die rechte Hand gegen die Admin-KARTE --
die es nicht mehr gibt; sie lief gegen `undefined`. Ersatz ist das
Zeichen selbst, und der Kommentar sagt, dass das schwaecher ist.
- pruef-haus-trennung: Der zweite DogFather entsteht jetzt im Bestand
statt ueber die Schnittstelle, und DASS die Schnittstelle ihn
ablehnt, ist der erste Prueffall geworden. Sonst waere "nie den
letzten DogFather" ab heute ungeprueft -- weil ihre Voraussetzung
schwerer herzustellen ist.
- pruef-creator-anlegen: aus einer Aussage zwei (die vier sind da UND
admin fehlt).
Gruen: personen-liste, personen-kachel, verborgen, manager-sicht,
creator-anlegen, haus-trennung, personen-formular, spicy, rollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
bea1bb7194 |
Die rechte Hand meldet wie das Team, die Leiste wird ein Universum, sein Kalender bleibt ganz
Drei Wuensche aus zwei Bildschirmfotos und einem Satz. === 1. SIE DARF SAGEN, WAS PASST UND WAS NICHT === Filipe: "die rechte hand soll bei diesen aufgaben auch wie die modis sagen koennen ob es passt oder nicht ... die rechte hand ist da um mir zu helfen aber auch wie die modis um mir zu sagen was passt und nicht wo die denken bedarf oder nicht. perfektionier das alles." SIE KONNTE ES NICHT, UND ZWAR AN DREI STELLEN GLEICHZEITIG -- die zweite und dritte kamen erst zum Vorschein, nachdem die erste behoben war. Genau deshalb steht "perfektionier das alles" ueber diesem Commit und nicht "eine Zeile geaendert": ERSTENS: Die Frage "an wessen Liste arbeitest du?" kannte nur Creator und Modis (dann die eigene). Sie fiel durch beide Zweige und konnte ueberall antworten, nirgends urteilen. ZWEITENS: Nach der Reparatur durfte sie -- und bekam den KATALOG DER CREATOR. Ihre Meldung trug einen Schluessel, den der Eingang gar nicht kennt, und wurde dort stillschweigend uebersprungen. Die Pruefung meldete "sie darf urteilen (200)" und eine Zeile spaeter "ihre Meldung steht NICHT in DogFathers Eingang". Beides stimmte. DRITTENS: Der Eingang sammelt aus der Liste der Teammitglieder, und die hiess `rolle = 'modi'`. Sie war die Empfaengerin dieser Seite und kam auf ihr selbst nicht vor. Wer nicht in der Liste steht, kann melden, so viel er will -- es erreicht niemanden. Jetzt steht sie in derselben Liste (aber `id <> ich`: eine Karte ueber sich selbst ist kein Ueberblick, sondern ein Spiegel), bekommt denselben Beobachtungskatalog wie die Modis und meldet in denselben Eingang. Alle Rollenvergleiche kommen dabei aus der vorhandenen Menge TEAM_DOGI_ROLLEN statt als zwei Vergleiche danebengeschrieben -- sonst steht dort beim naechsten Mal einer zu wenig. === 2. DIE LEISTE === Filipe: "der hintergrund dieser leiste soll extrem speziell aussehen wie ein universum und soll von lila auf babyblau wechseln, von links nach rechts ... der husky links soll auch babyblau strahlen und nicht rot und der rechts lila. dan brauch ich auch noch einen teilen button." DIE RICHTUNG IST DIE EIGENTLICHE AENDERUNG: Der Schein lief von UNTEN nach oben (die Glut der Agenturseite, nur in Lila). Jetzt von LINKS nach rechts, mit zwei Nebeln und sieben Sternen -- als Verlaufslagen und nicht als Elemente: Sieben Punkte waeren sieben Knoten im Baum auf jeder der zwanzig Seiten, nur fuer Zierde. DIE ZEICHEN TAUSCHEN DIE SEITEN. Links stand ein warmes Rot, fest hingeschrieben in start.css; rechts strahlte der zweite Husky babyblau. Jetzt umgekehrt -- so hat jede Seite der Leiste beide Farben, statt dass jede nur eine hat. Beim rechten wird die FUELLUNG mitgetauscht, nicht nur der Schein: Ein lila Schein um ein blaues Zeichen waere ein Rand, keine Farbe. "UEBERTRIEBEN GEIL" HAT EINE GRENZE, und sie ist gemessen, nicht geschaetzt. Erster Anlauf: .30 -- der Verlauf war zu ahnen, nicht zu sehen, Kontrast 5,26:1. Zweiter: .40 -- sichtbar, aber 4,79:1 in der Mitte, bei einer Grenze von 4,5 zu knapp. Jetzt kraeftige Enden und eine zurueckhaltende Mitte: 5,92 / 5,26 / 7,06:1 an drei Stellen des Verlaufs, gemessen an echten Bildpunkten. Die Farbe liest das Auge an den Enden; in der Mitte gewinnt die Lesbarkeit. DER TEILEN-KNOPF fehlte, weil `DARF_TEILEN` Leitung und Scouts kennt -- die rechte Hand ist keins von beidem. Gefragt wird jetzt nicht nach der Rolle, sondern nach `ich.marke`: Die setzt der Server genau dann, wenn jemand zu Team Dogi gehoert. Der Rollenname bleibt damit aus einer Datei heraus, die jeder herunterlaedt -- und die Frage lautet ohnehin "gehoert diese Person hierher?". === 3. SEIN KALENDER BLEIBT GANZ === Filipe: "mein kalender (dogfather) auf dieser seite hier soll komplett verbunden sein mit dem kalender in der workspace seite ABER NUR IN DER DOGFATHER ROLLE BEI DOGFATHER: NICHT BEI VANVAN." Bei Aufgaben, Bereichen und Dateien ist die Haustrennung eine Hilfe -- man will das andere Haus dort gerade nicht sehen. Beim Kalender waere sie eine Falle: Wer auf der Team-Seite einen Termin eintraegt und die Haelfte seines Tages nicht sieht, legt ihn auf eine Zeit, in der er schon woanders sitzt. Ein Kalender, der nur die halbe Wahrheit zeigt, ist schlimmer als keiner. Geprueft wird die ROLLE und nicht der Name -- ein Name waere die Stelle, an der es beim naechsten Menschen bricht. === WAS DIE PRUEFUNGEN GEZEIGT HABEN === Eine Erwartung war seit Stunden stumm rot: pruef-modi-checkliste verlangte GENAU EINE Zusatzkachel, und seit dem Ideen-Board sind es drei. Ich hatte sie nach der Aenderung nicht noch einmal laufen lassen. Sie zaehlt jetzt nicht mehr auf eine feste Zahl, sondern prueft die AUSSAGE: Wer welche bekommen soll, bekommt welche -- und jede gehoert in die Gruppe "Team Dogi". Eine Pruefung, die bei jeder neuen Kachel rot wird, erzieht dazu, ihr Rotwerden zu ignorieren. Zwei weitere Erwartungen haben sich gedreht und sind im Quelltext begruendet: Der Kalender auf crew. zeigt DogFather jetzt alles (die Pruefung unterscheidet dafuer ER-ja/SIE-nein statt einer einzelnen Antwort -- das ist mehr, nicht weniger), und "aus dem Eingang verschwunden" fragt jetzt nach Schluessel UND Person: Seit die rechte Hand denselben Katalog benutzt, koennen zwei Menschen denselben Punkt melden, und die Pruefung meldete einen Fehler, den es nicht gab. Und eine war wertlos: "die rechte Hand sieht den Agenturtermin nicht" lief gegen einen leeren Kalender -- sie sah ueberhaupt nichts. Sie hat jetzt zwei eigene Termine, einen aus jedem Haus; erst damit sagt die Messung etwas. pruef-modi-checkliste 59 -> 70 · pruef-team-stufen 24 -> 26 · pruef-team-ampel 32 · pruef-haus-trennung 61 -> 62 · pruef-rollen 278 · pruef-css-klassen gruen · pruef-modi-wortleck 5. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
da7ddf7b5e |
Alle Kategorien in der Personenliste -- und die rechte Hand liest mit
Filipe, mit Bildschirmfoto der Team-Seite: "ich muss alle kategorien da sehen. und ich will dass die rechte hand auch alle sieht." AUF DEM BILD STAND EIN EINZIGER ABSCHNITT: DogFather. VanVan war in derselben Minute zur rechten Hand geworden (im Protokoll darunter zu sehen: "#4 VanVan: admin -> hand") -- und damit aus der Liste VERSCHWUNDEN. Nicht aus der Antwort des Servers. Der schickte sie die ganze Zeit mit. `assets/js/personen.js` gruppiert nach einer Liste mit fuenf Rollen, und wer dort nicht steht, wurde nicht gezeichnet: kein Fehler, keine Luecke, kein Hinweis. Dieselbe stille Lücke wie vorgestern in der Personenauswahl des Chats, an einer anderen Stelle -- und dieselbe Ursache: Die Namen der verborgenen Rollen duerfen in keiner ausgelieferten Datei stehen, also kannte der Browser sie nicht. DIE LOESUNG IST DIESELBE: Der Server schickt die Ueberschriften mit (`zusatzrollen` -- es gab sie schon, sie waren bisher nur die Auswahl beim Anlegen). Der Browser braucht dafuer keinen Rollennamen zu kennen, er bekommt einen Text. UND DARUNTER EIN AUFFANGBECKEN, das ist der eigentliche Fortschritt: Kaeme morgen eine siebte Rolle und niemand daechte an diese Stelle, stuenden ihre Leute trotzdem auf der Seite -- unter ihrem Rollennamen, sichtbar, statt lautlos zu fehlen. Ein Abschnitt mit einer unschoenen Ueberschrift ist tausendmal besser als ein Mensch, den es auf dem Bildschirm nicht gibt. DIE RECHTE HAND LIEST MIT -- LESEND. Das ist sein eigenes Wort ("sieht"): Codes, Sperren, Loeschen, Rollen vergeben und das Protokoll bleiben bei DogFather. Die Ausnahme im Server ist Wort fuer Wort so gebaut wie die, die Spicy Media schon hat: eine Methode, eine Adresse, eine Rolle. Zwei Fassungen derselben Ausnahme waeren zwei Regeln, und die zweite laesst irgendwann mehr durch als gedacht. DREI SCHICHTEN MUSSTEN ZUSTIMMEN, und die dritte hatte ich uebersehen: die Kachel, die Schnittstelle -- und die SEITE selbst. In der Rollentabelle in workspace.js stand personen.html fuer spicy, admin und manager; die rechte Hand flog von der Seite auf die Startseite zurueck, obwohl Kachel und Daten schon stimmten. Gefunden hat das nicht das Auge, sondern pruef-rollen. Sie geht jede Kachel jeder Rolle ab und schaut nach, wo man landet: "Rechte Hand Kachel personen.html LANDET AUF start.html". Das ist der Wert dieser Pruefung -- der Fehler war unsichtbar, solange man nicht selbst als rechte Hand auf die Kachel drueckt. EINE ERWARTUNG HAT SICH GEDREHT, und das steht jetzt im Quelltext: pruef-haus-trennung verlangte vor einer Stunde noch, dass die Kachel bei ihr NICHT steht und die Seite sie abweist -- richtig, solange sie die Seite nicht durfte. Die Pruefung ist dadurch nicht schwaecher geworden: Sie verlangt weiterhin, dass Kachel und Zugang DASSELBE sagen. Sie sagen jetzt beide ja statt beide nein. DIE NEUE MESSUNG VERGLEICHT ZAHL GEGEN ZAHL: wie viele Menschen der Server liefert, wie viele Zeilen auf dem Bildschirm stehen. Nicht "steht VanVan da" -- das waere ein Name, den man beim naechsten Umbau so lange anpasst, bis die Pruefung wieder passt. Eine Pruefung, die nur die Antwort des Servers ansieht, waere hier uebrigens gruen gewesen. Beim Schreiben dieser Messung ist sie zuerst viermal falsch angeschlagen: Die Abschnitte stehen zugeklappt da, und zugeklappt sind ihre Zeilen gar nicht im Dokument. Vier Fehler, die es nicht gab -- die Pruefung klappt jetzt erst auf, dann liest sie. pruef-personen-formular 27 -> 35 · pruef-haus-trennung 53 -> 61 · pruef-rollen 277 -> 278 · pruef-modi-verborgen 80 · pruef-start-ansicht 143 · pruef-css-klassen gruen · pruef-modi-wortleck 5. ANMERKUNG ZUR TEAM-ADRESSE: Dort zeigt die Liste weiterhin nur Team Dogi -- so, wie er es eine Stunde vorher verlangt hat ("bitte nur basiert auf diese seite"). "Alle Kategorien" heisst also: alle des Teams. Wenn er dort auch die Agentur sehen will, ist das eine Zeile, aber es waere eine andere Entscheidung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
670ce4a5c1 |
Personen & Zugaenge auf der Team-Seite -- und eine Rolle laesst sich endlich aendern
Filipe wollte VanVan die Rolle "Rechte Hand" geben. Auf die Frage nach ihrem Code: "die kategorie personen & zugaenge fehlt also muss das hinzugefuegt werden und bitte nur basiert auf diese seite." BEIM NACHSEHEN KAMEN ZWEI DINGE HERAUS, und das zweite war das eigentliche: Die Kachel fehlte, weil ich sie mit den Agenturkacheln entfernt hatte -- ausgerechnet die, mit der man jemandem eine Rolle gibt. Die Team-Adresse war damit eine Seite, auf der man das Team nicht verwalten kann. UND ES GAB DIE FUNKTION GAR NICHT. Im ganzen Server aendert keine einzige Stelle `personen.rolle`. Anlegen ja, sperren ja, loeschen ja -- aendern nirgends, seit dem ersten Tag. Wer jemandem eine andere Aufgabe geben wollte, musste ihn loeschen und neu anlegen, und daran haengen seine Aufgaben, seine Nachrichten, seine Eintraege, sein ganzer Verlauf. Kapitel 4 des Pflichtenhefts verlangt ausdruecklich das Gegenteil. (Nebenbefund aus derselben Messung, ihm gemeldet: Auf dem Server gibt es KEINE Rolle 'hand'. VanVan ist ein zweiter DogFather-Zugang. Die Rueckmeldungen mit "nur an DogFather" wuerde sie deshalb heute mitlesen -- die Regel fragt "ist das DogFather?", und ihre Rolle antwortet ja.) DIE KACHEL traegt Namen, Zeichen und Farbton der Agenturseite. Es ist dieselbe Seite mit demselben Zweck; ein zweiter Name dafuer waere ein zweites Ding, das es nicht gibt. SIE STEHT NUR DORT, WO SIE AUCH FUNKTIONIERT. Die Personenseite haengt serverseitig an `nurAdmin`. In der Kachelliste der rechten Hand haette sie auf eine 404 gefuehrt -- ein Knopf, der eine Absage bringt, ist schlimmer als kein Knopf. Wenn sie das duerfen soll, ist das eine eigene Entscheidung und gehoert an dieselbe Stelle wie nurAdmin. "NUR BASIERT AUF DIESE SEITE" steht nicht in der Kachel, sondern im Server: Auf crew. liefert die Liste nur Team Dogi, und angelegt werden koennen nur Team-Rollen. Beides kommt aus Funktionen, die es schon gab (hausBedingung, darfAnlegen) -- und `darfAnlegen` baut auch die Knoepfe in der Oberflaeche, weshalb die anderen Rollen dort von selbst verschwinden statt eine Absage zu bringen. DER ROLLENWECHSEL HAT FUENF SICHERUNGEN, und jede hat ihren Grund: NUR DOGFATHER -- wer Rollen vergeben kann, kann sich selbst zum DogFather machen. NIE DIE EIGENE. Wer sich selbst herabstuft, sperrt sich aus; die Funktion zum Zurueckdrehen haengt an der Rolle, die er gerade abgegeben hat. Das ist keine Warnung wert, das ist eine Tuer, die zubleibt. NIE DEN LETZTEN AKTIVEN DOGFATHER. Gezaehlt werden die AKTIVEN: Ein gesperrter kann niemanden hereinlassen, ihn mitzuzaehlen waere eine Sicherung, die sich selbst beluegt. ALLE SITZUNGEN DIESER PERSON ENDEN. Eine Sitzung gehoert seit dem 10.09.2026 zu einer ADRESSE, und welche das ist, entscheidet die Rolle. Wer eben noch DogFather war und jetzt rechte Hand ist, saesse sonst mit einer Sitzung da, die auf der Agenturadresse laeuft und dort nicht mehr hingehoert -- ein halb gueltiger Zustand, der erst beim naechsten Klick auffaellt. DER CODE BLEIBT. Er haengt am Menschen, nicht an der Rolle. Ihn mitzutauschen waere bequem und falsch: Dann muesste jede Rollenaenderung von einem Gespraech begleitet sein, und wer das vergisst, sperrt jemanden aus, ohne es zu merken. Und es steht im Protokoll, mit beiden Rollen im Klartext. DIE AUSWAHL IM BROWSER wird nicht noch einmal gebaut, sondern aus dem Anlege-Formular gelesen. Dort stehen genau die Rollen, die der Server dieser Person zugesteht -- einschliesslich derer, die in keiner ausgelieferten Datei stehen duerfen und erst nachtraeglich dazukommen. Eine zweite Liste waere die, in der eine Rolle fehlt oder eine zu viel steht, und beides faellt erst auf, wenn jemand sie braucht. EINE PRUEFUNG WAR WERTLOS UND IST ES NICHT MEHR: "ihre Sitzungen sind beendet" lief gegen einen leeren Bestand -- ein gruener Haken ueber einer Null. Jetzt meldet sich die Person vorher an, und die Zahl davor muss groesser als null sein. pruef-haus-trennung 32 -> 53 · pruef-rollen 277 · pruef-personen-formular 27 · pruef-css-klassen 30 · pruef-start-ansicht 143 · pruef-modi-verborgen 78 · pruef-modi-wortleck 5. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
9c99a5b9c3 |
Zwei Haeuser auf einer Datenbank -- die Team-Adresse zeigt nur das Team
Filipe, mit Bildschirmfoto der Zentrale: "die daten von dieser seite
sollen nichts mit den daten am hut haben von der workspace seite bitte,
die hier soll ihre eigene daten haben und komplett von der anderen
getrennt sein. dogfather soll die daten auch auf der anderen seite
sehen in der team dogi kategorie aber auch nur er und vanvan."
GETRENNT WIRD DER AUSSCHNITT, NICHT DER BESTAND. Eine zweite Datenbank
haette den zweiten Satz unmoeglich gemacht -- er will dieselben Daten
auf beiden Adressen sehen. Es bleibt also alles an einem Ort, und die
ADRESSE entscheidet, welcher Ausschnitt davon herauskommt.
ALLES HAENGT AN EINEM WERT: `person.haus`, gesetzt in sitzungLesen()
aus dem Hostnamen. Von dort reist er mit der Person durch jede
Sichtbarkeitsregel im Haus. Der Grund ist ein praktischer: Die Regeln
bekommen ueberall dieselbe Person gereicht -- sichtbar(person),
sichtbareCreatorIds(person), bereicheFuer(person). Ein zusaetzliches
Argument haette an ueber dreissig Aufrufstellen mitgeschleift werden
muessen, und die eine vergessene waere das Loch gewesen.
RECHTE AENDERT ES NICHT. Es entscheidet, WAS jemand sieht, nicht, was
er darf -- wie die Sicht eines anderen (sichtPerson) das auch nicht tut.
DER FILTER IST DER SPIEGEL EINES VORHANDENEN. Es gab schon
`ohneTeamDogi` ("alles ausser dem Team") fuer Spicy Media. Dazu kommt
jetzt `ohneAgentur` -- gleiche Bauweise, andere Rollenmenge, GEMEINSAME
Implementierung. In der steckt die NULL-Falle (`IS NULL OR NOT IN`,
denn `NULL NOT IN (...)` ist weder wahr noch falsch), und die sieht man
einer Abschrift nicht an.
WARUM NICHT "MINDESTENS EINE SPALTE ZEIGT AUF TEAM DOGI": Das waere die
naheliegende Formulierung und sie waere falsch. Eine Aufgabe, die
DogFather fuer einen Creator anlegt, haette ueber `erstellt_von` (er
gehoert zum Haus) trotzdem gepasst und stuende auf der Team-Seite.
Andersherum stimmt es: Sobald IRGENDEINE Spalte auf Creator, Scout,
Manager oder Spicy Media zeigt, gehoert die Zeile ins andere Haus.
VIER TUEREN, EINE FORM. Aufgaben, Bereiche, Dateien und der Kalender
haben je eine eigene sichtbar()-Funktion. Alle vier bekommen dieselbe
Bedingung an derselben Stelle, in derselben Schreibweise -- damit keine
davon anders aussieht als die anderen. Beim Kalender steht sie in
termineSichtbar() in workspace.js und nicht im Kalendermodul: Sonst
haetten Termine, Wiederholungen und der ICS-Abruf sie einzeln
gebraucht, und der ICS-Abruf ist der, den man vergisst -- er laeuft
ohne Bildschirm.
ZWEI ABFRAGEN GEHEN ABSICHTLICH NICHT DURCH DIE LISTENFUNKTIONEN, und
genau die standen im Bildschirmfoto: der Ring der Zentrale ("9 IM
TEAM", obwohl das Team drei Leute hat -- gezaehlt wurde das ganze Haus)
und die Hinweiszeile darunter ("Creator-Profile sind noch leer"). Im
Quelltext der Zentrale steht sogar ausdruecklich, dass sie die einzige
solche Stelle ist; gefunden habe ich sie trotzdem erst, weil ich der
Zahl im Bild nachgegangen bin. Beide bekommen die Bedingung jetzt aus
derselben Funktion (`hausBedingung`), nicht aus einer zweiten
Rollenliste.
Die Hinweis-Bedingung sitzt am BLOCK und nicht an den vier Abfragen
darin: Wer eine fuenfte hinzufuegt, bekommt sie dadurch mit, ohne daran
zu denken.
DIE KACHELN: Auf crew. liefert der Server dieselbe Liste wie der
rechten Hand -- nicht eine dritte. Fuenfundzwanzig Kacheln, von denen
zwei Drittel Creator und Agentur betreffen, waeren dort Fenster in ein
Haus, in dem er gerade nicht ist, und hinter jedem stuende seit heute
eine leere Liste. Auf workspace. bleibt alles, wie es war: Dort schickt
der Server weiterhin `bereiche: null` ("nimm die Liste aus der Datei").
JEDE MESSUNG STEHT ZWEIMAL DA. Die Trennung kann auf zwei Arten falsch
sein: Sie greift nicht (dann steht die Agentur weiter auf der
Team-Seite, und niemand merkt es, weil alles funktioniert), oder sie
greift zu weit (dann verschwindet auf der Agenturseite etwas -- der
gefaehrlichere Fall, denn eine zu kurze Liste sieht aus wie "nichts zu
tun"). Deshalb folgt auf jede Messung auf crew. dieselbe Messung auf
workspace., mit DERSELBEN Sitzung; der einzige Unterschied ist der
Host-Kopf. Dazu zwei Gegenproben zur Regel selbst: 127.0.0.1 bleibt
unberuehrt (sonst waeren alle Pruefungen im Haus stillschweigend blind
geworden), und eine erfundene Adresse oeffnet kein drittes Haus.
NEBENBEI ZWEI EIGENE FEHLER BEHOBEN: pruef-chat-kanaele und
pruef-rueckmeldung liefen auf Ports, die schon vergeben waren (4359
neben pruef-modi-verborgen, 4371 neben pruef-crew-adresse). Beide sind
umgezogen. Fuenf weitere Doppelungen zwischen fremden Pruefdateien
(4186, 4188, 4189, 4193, 4198) bleiben stehen und sind gemeldet -- an
Dateien zu greifen, an denen gerade eine zweite Sitzung arbeitet, waere
genau der Fehler, den diese Doppelungen ohnehin schon zeigen.
pruef-haus-trennung 32 (neu) · pruef-rollen 277 · pruef-modi-verborgen
78 · pruef-chat gruen · pruef-rueckmeldung 30 · pruef-modi-ideen 30 ·
pruef-crew-adresse 129 · pruef-start-ansicht gruen ·
pruef-zwischenspeicher 21 · pruef-modi-wortleck 5.
BERICHTIGUNG zum vorigen Commit: Dort steht "pruef-rueckmeldung 34".
Es sind 30. Ich hatte die Zeilen geschaetzt statt sie zu lesen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|