2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	5bde49e0cd	Was unten im Brett steht, steht jetzt auch oben im Band ... Filipe am 22.09.: "die aufgaben die man unten sieht soll man auch oben sehen." GEMESSEN an den echten Daten: aufgaben_zuteilung hatte NULL Zeilen, waehrend im Brett zwei Aufgaben standen (OFFEN 1, IN ARBEIT 1). Jede Person las oben "nichts zugeteilt". Die Aufgaben hingen am aelteren Feld aufgaben.verantwortlich_id -- genau dem Feld, nach dem das Brett gruppiert. Die Uebersicht las eine andere Quelle als die Liste darunter. resuemeeFuer() zaehlt jetzt BEIDE Wege und keinen doppelt: Gibt es zu einer Aufgabe eine Zuteilungszeile fuer die Person, gewinnt die Zuteilung (genauerer Zustand). Nur wo keine Zeile existiert, zaehlt das alte Feld. Die Zuordnung status->zustand steht an EINER Stelle; "review" zaehlt wie "arbeit", "abgebrochen" zaehlt nirgends -- so wie im Brett auch. Die Personenliste wird nicht mehr aufgezaehlt, sondern abgeleitet: die Rollen des Hauses (immer, auch mit null Aufgaben -- wer frei ist, ist die haeufigste Frage) PLUS jede aktive Person, der eine Aufgabe gehoert. Ohne den zweiten Teil koennte im Brett eine Aufgabe stehen, deren Mensch oben fehlt. pruef-zuteilung 71/0 (war 65). Der neue Abschnitt legt eine Aufgabe GENAU SO an wie die echten alten -- verantwortlich_id, keine Zuteilungszeile -- und misst Filipes Satz direkt: "unten im Brett stehen genauso viele wie oben (2 = 2)". Zahl in der Bedingung, nicht nur im Meldetext. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-22 09:12:20 +02:00
DogFatherGit	ef0fddc724	Aufgaben an Menschen: zuteilen, annehmen, ablehnen, bewerten ... Auftrag vom 21.09.2026, Abschnitte 2 bis 5 -- der Serverteil. DREI ARTEN ZU VERTEILEN, und der Unterschied zwischen den letzten beiden ist der ganze Punkt: einzeln eine Person, sie macht es mehrere mehrere Personen, JEDE macht ihren Teil pool mehrere sehen es, EINE nimmt es -- danach ist es fuer die anderen weg, damit niemand doppelt arbeitet EINE EIGENE TABELLE, KEINE SPALTEN AN DER AUFGABE. Abschnitt 4 verlangt ausdruecklich: *"Die Aufgabe muss in der Auswertung auf die einzelnen zugewiesenen Personen aufgeteilt werden"* -- und gleichzeitig soll "die urspruengliche gemeinsame Aufgabe ihre uebergeordnete Struktur" behalten. Eine Aufgabe hat EINEN Titel und EINE Frist, aber je Mensch einen eigenen Stand, einen eigenen Grund beim Ablehnen, ein eigenes Erledigt-Datum und eine eigene Rueckmeldung. Das in Spalten zu pressen hiesse, dieselbe Aufgabe mehrfach anzulegen. `aufgaben.status` bleibt daneben unberuehrt. Zwei Ebenen, weil es zwei Fragen sind: "Wie steht die Aufgabe?" und "Wie steht sie bei IHM?" Ein einziges Feld koennte bei drei Leuten nicht gleichzeitig "angenommen" und "abgelehnt" sein. DER WICHTIGSTE EINZELNE HANDGRIFF -- und er steht nicht im Auftrag: Wer eine Aufgabe BEKOMMEN hat, sieht sie jetzt immer. Bei "mehrere" und "pool" bleibt `verantwortlich_id` leer, und die alten Sichtregeln fragen genau danach. Ohne die Erweiterung stuende eine Aufgabe im Resuemee der Leitung und waere fuer den, der sie machen soll, unsichtbar -- der unangenehmste denkbare Fehler in einem Aufgabensystem, und man sieht ihn nirgends. Die Erweiterung ist ein ODER, kein UND: Sie erweitert die Sicht, die Haustrennung darueber bleibt ein UND und wirkt weiter. WAS SONST NOCH ENTSCHIEDEN WURDE, mit Grund im Code: - Ablehnen braucht eine Begruendung (mind. 3 Zeichen). Ein leeres Nein ist fuer den, der verteilt hat, keine Information -- er muss dann nachfragen, und genau das sollte die Nachricht ersparen. - "Verbesserungsmoeglichkeiten" braucht einen Text. Ein leeres "kann besser" sagt nichts ausser, dass jemand unzufrieden war. - Bewertet wird erst, wenn jemand FERTIG ist. Eine Rueckmeldung auf etwas, das noch laeuft, ist keine Bewertung, sondern eine Einmischung. - Beim Pool wird VOR dem Schreiben gefragt, ob schon jemand zugesagt hat -- sonst nehmen zwei im selben Moment dieselbe Aufgabe und beide sehen "hat geklappt". - Wer schon geantwortet hat, behaelt seinen Stand, wenn die Aufgabe noch einmal gespeichert wird. Sonst muesste er ohne Grund erneut zusagen. - Wer nicht mehr dabei ist, faellt raus -- aber nur, solange er noch nicht geantwortet hat. Jemandem eine angenommene Aufgabe wegzunehmen, ohne dass er es erfaehrt, waere die unangenehmste Art, Arbeit zu verlieren. - "pool" mit einer Person wird "einzeln". Ein Pool aus einem Menschen ist keiner. `verantwortlich_id` bleibt und wird mitgefuehrt (einzeln = die Person, pool = der Uebernehmer, mehrere = leer): Brett, Startseite und Uebersicht gruppieren danach. Drei gewachsene Ansichten gleichzeitig umzubauen waere der groessere Eingriff -- und im haeufigsten Fall sagen beide dasselbe. KEIN CHECK an der nachgetragenen Spalte `verteilart`, mit Absicht: Ein CHECK auf einer nachgetragenen Spalte hiesse, die Tabelle neu zu bauen -- der Weg, der in diesem Haus am 11.09. und heute schon Spalten gekostet hat. Geprueft wird beim Schreiben. pruef-zuteilung.mjs, 48 Aussagen -- ein Arbeitstag durchgespielt. Ein Fehlschlag beim ersten Lauf, und er war lehrreich: "Cem hat keinen eigenen Stand" schlug fehl, weil Cem die Aufgabe gar nicht SIEHT (`null?.x` ist `undefined`, nicht `null`). Die Zusicherung konnte "sieht sie nicht" und "sieht sie ohne Stand" nicht unterscheiden -- also pruefte sie beides nicht richtig. Dass er sie nicht sieht, ist genau Abschnitt 1: *"Eine Modi darf nicht automatisch die vollstaendige Aufgabenuebersicht aller anderen Modis sehen."* Beide Faelle stehen jetzt einzeln da, mit einer Gegenprobe, dass seine Liste ueberhaupt laedt. Nachbarn gruen: pruef-verteilen 16/0, pruef-aufgabenbrett 49/0, pruef-umstellung 18/0.	2026-09-21 17:52:52 +02:00