731537b6827e0f512f32bb54dba3bfa37a93c91c
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
731537b682 |
Eine Wahrheit statt zwei: Der Status der Aufgabe gilt
VanVan im Support (Runde 1, „Ging noch nicht"): „Das dort steht ich
bewerbe mich ist jetzt weg, aber dafür hat er noch mal 2 Buttons
hinzugefügt mit ich fange an und fertig. Wenn man auf ich fange an
drückt steht dort in Bearbeitung und wenn man auf fertig drückt dann
wird es zu erledigt. Die Aufgabe bleibt aber im status offen stehen.
Die beiden Buttons können entfernt werden, weil es darüber ja den
button starten gibt, der auch korrekt funktioniert."
SIE HAT ETWAS GROESSERES GEFUNDEN ALS ZWEI UEBERFLUESSIGE KNOEPFE.
Es gab ZWEI Zustaende nebeneinander, und sie kannten sich nicht:
aufgaben.status offen · arbeit · review · erledigt
aufgaben_zuteilung.zustand angenommen · arbeit · erledigt
Die zwei Knoepfe setzten den zweiten (`/mein-stand`), der
Starten-Knopf den ersten. Auf der Karte stand „in Bearbeitung", in der
Liste „offen" -- und beides stimmte. Das ist schlimmer als ein Fehler:
Es gibt nichts, dem man glauben kann. Zwei Antworten auf dieselbe
Frage sind in diesem Haus verboten, und genau das war es.
WAS ICH BEINAHE FALSCH GEMACHT HAETTE
Ihr Wunsch war „entfernt die Knoepfe". Bevor ich das tue, habe ich
gemessen, was danach bliebe -- am Bildschirm einer Modi mit einer
angenommenen Aufgabe:
Karten-Knoepfe: []
Schritt-Knoepfe: []
KEIN EINZIGER. Die Modi sieht den Starten-Knopf NICHT, weil
`darfAendern` fuer sie falsch ist: Sie ist weder Leitung noch
`creator_id`, `verantwortlich_id` oder `erstellt_von` -- die Zuteilung
laeuft ueber eine eigene Tabelle. VanVan ist Leitung und sieht ihn;
deshalb klang „den gibt es doch" selbstverstaendlich.
Haette ich die Knoepfe einfach geloescht, haette ich der Modi die
einzige Handlung weggenommen, die sie hatte -- eine Meldung „behoben",
nach der weniger geht als vorher.
ALSO WIRD IHR SATZ WAHR GEMACHT
1. Wer eine Aufgabe WIRKLICH hat (angenommen/arbeit/erledigt), darf
ihren STATUS setzen. Damit sieht die Modi denselben Knopf wie alle
-- gemessen: „Schritt-Knoepfe: [starten ▶]".
ENG GEFASST: nur der Status, nur allein in der Anfrage. Die
Pruefung ist `Object.keys(...).length === 1` und nicht „enthaelt
status" -- sonst waere die schmale Tuer die breite mit einem
Zusatzfeld.
2. Der Statuswechsel zieht die Zuteilung MIT. Ohne das waere das
Entfernen eine stille Verschlechterung gewesen: Die Zaehler einer
Person („offen / in Arbeit / erledigt") lesen die ZUTEILUNG, nicht
die Aufgabe. Jede Zuteilung waere fuer immer auf „angenommen"
stehen geblieben, und die Zahlen haetten aufgehoert, die
Wirklichkeit zu zeigen -- ohne dass irgendwo etwas rot wird.
ABGELEITET, NICHT ZWEIMAL GESCHRIEBEN: `STATUS_ALS_ZUSTAND` gibt
es seit dem 22.09. Benutzt wird genau sie, mit EINER Abweichung,
und die steht daneben: Wer zugesagt hat, faellt beim Zurueckdrehen
auf „angenommen", nicht auf „offen". Eine Zusage verschwindet
nicht, weil jemand den Status zurueckstellt.
3. Die zwei Knoepfe sind weg. Der Weg `/mein-stand` bleibt -- er ist
die Schranke fuer den, der die Schnittstelle direkt anspricht.
GEGENPROBEN ZUM ERWEITERTEN RECHT (ein Recht ohne Gegenprobe ist ein
Loch mit Begruendung):
Anna hat eine Aufgabe, die ihr NUR zugeteilt ist
(darf_aendern false, darf_status true)
sie setzt den Status ihrer Aufgabe (200)
mit einem zweiten Feld kommt sie nicht durch (403)
und umschreiben darf sie gar nicht (403)
der Titel steht unveraendert da („Clips schneiden")
und wer sie nicht hat, setzt auch keinen Status (404)
zurueckgedreht steht Anna wieder auf „angenommen"
eine Bewerbung bleibt eine Bewerbung (abgelehnt -> abgelehnt)
ZWEI EIGENE FEHLER, BEIDE VON DER MESSUNG GEFUNDEN:
· Mein erster Zeuge war Bea und die Pool-Aufgabe. Die Gegenprobe
wurde rot: Bea darf sie ohnehin umschreiben, weil das Uebernehmen
aus dem Pool sie verantwortlich macht. An ihr laesst sich ueber die
neue, schmale Tuer gar nichts zeigen. Der reine Fall wird jetzt
GESUCHT (darf_aendern falsch, Zuteilung angenommen) statt
hingeschrieben -- eine feste Nummer waere die naechste, die beim
naechsten Umbau nicht mehr stimmt.
· Mein Abschnitt stellte Annas Aufgabe auf „arbeit" und liess sie so
stehen; ein spaeterer zaehlte ihre „angenommen" und wurde dadurch
rot. Eine Pruefung, die den Bestand fuer die naechste veraendert,
misst ab da etwas anderes als sie glaubt. Jetzt raeumt sie auf --
und die Rueckfahrt ist selbst eine Messung.
ZWEI PRUEFUNGEN MUSSTEN MITZIEHEN, und das ist richtig so: Beide
verlangten „Ich fange an" -- geschrieben von mir am 30.09. fuer
VanVans ERSTE Meldung. Ihre Absicht bleibt woertlich dieselbe („kann
sie wirklich etwas tun?"), nur ist der Griff jetzt der Statusknopf.
`knoepfeAn` sieht dafuer auch neben den Zuteilungsblock: „kann sie
etwas tun?" laesst sich am Block allein nicht beantworten.
GEPRUEFT: pruef-zuteilung 75 -> 90 ok · pruef-bewerbung-aufgaben
162 -> 164 ok · pruef-struktur 99 · pruef-resuemee 35 ·
pruef-aufgabenbrett 49 · pruef-rechtetafel 19 ·
pruef-aufgaben-vorlagen 46.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2f3b8630c7 |
Messungen am Telefon: 37 bekommen ihren Finger
Gestern Mittag gemessen: 39 `newContext`-Aufrufe nehmen ihre Breite
aus einer Variablen und setzen kein `hasTouch`. Ohne das meldet der
Browser `pointer: fine`, und KEINE Regel aus `@media (pointer:
coarse)` greift — dort stehen im ganzen Haus die 44-Pixel-
Beruehrziele, die ausgeblendeten Tastenkuerzel und die
eingeklappte Reiterleiste.
Was das anrichtet, war an pruef-breiten zu sehen: drei Befunde auf
320, 390 und 430 Pixeln, die mit dem Finger allesamt verschwanden —
Messfehler, keine Fehler.
37 DAVON HABEN IHN JETZT. Nur `hasTouch`, nicht `isMobile`: Gefragt
ist genau die eine Sache, um die es geht. `isMobile` waere eine
zweite Aenderung in derselben Zeile, und wenn danach etwas anders
aussieht, wuesste niemand, welche von beiden es war.
ZWEI BLEIBEN STEHEN, beide in pruef-grosscheck.mjs. Die Aenderung
dort waere ein Zweizeiler; sie zu pruefen hiesse, 206 Seiten ueber
vier Rollen laufen zu lassen, und das braucht Filipes Zusage. Eine
Aenderung, die ich nicht pruefen darf, liefere ich nicht aus.
Grundlinie in pruef-fingermass steht deshalb auf 2.
JEDE EINZELN NACHGELAUFEN — 37 Laeufe:
34 gruen, darunter pruef-handy 186, pruef-material 159,
pruef-start-ansicht 160, pruef-kalender 141, pruef-erwaehnung 129,
pruef-bewerbung-aufgaben 163, pruef-neue-seiten 109
3 mit Befunden, ALLE DREI VORBESTEHEND (Gegenprobe: alter Stand
derselben Datei, gleicher Lauf, gleiche Zahl):
pruef-browser 3 (WebKit startet auf diesem Rechner nicht)
pruef-chat-anhaenge 2
pruef-crew-wand-bild 3
EINE ZEITBOMBE GEFUNDEN UND ENTSCHAERFT
pruef-dabei-optik meldete „Haekchen: 0 -> 0" — aber nur, wenn vier
andere Pruefungen gleichzeitig liefen. Allein: „0 -> 1", gruen.
Dort stand `waitForTimeout(250)` mit der Begruendung „250 ms sind
reichlich ueber den 160" (der Dauer der Blende). Auf einem Rechner,
auf dem nebenher vier Browser messen, sind sie es nicht. Die
Pruefung war damit gruen, solange nichts anderes lief, und rot im
Gesamtlauf — also genau dann, wenn niemand sie einzeln nachstellen
kann.
Eine Wartezeit ist eine Annahme ueber den Rechner. Gewartet wird
jetzt auf das, worauf es ankommt: dass das Haekchen da ist. Laeuft
die Frist ab, faellt die Pruefung mit dem ECHTEN Wert um und nicht
mit einem Messfehler. Gegenprobe: unter derselben vierfachen Last,
die sie vorher rot gemacht hat, jetzt gruen.
UND DIE GRUNDLINIE WIEDER STRENG. Ich hatte sie kurz auf
„hoechstens" gestellt — damit haette ein Rueckgang stillschweigend
Platz fuer die naechste Suende gedeckt. Genau davor warnt der Kopf
derselben Datei bei der anderen Grundlinie, und ich habe es eine
Stunde spaeter selbst falsch gemacht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8e18c7bcf0 |
Aufgaben: eine Bewerbung auf eine erledigte Aufgabe ist keine mehr
Beim Durchsehen der echten Daten am 30.09. gefunden, Filipe am 01.10.: „mach alles los." GEMESSEN: Zwei Bewerbungen von Miss standen auf „beworben" -- an Aufgaben, die laengst `erledigt` bzw. `review` waren. Bei ihr stand weiter „wartet auf Antwort", und in der Liste der Leitung stand eine Entscheidung an, die es nicht mehr gibt. DAS MUSTER GIBT ES IM HAUS SCHON. `uebernahmeAbschliessen` raeumt genau so die offenen Bewerbungen weg, wenn jemand anderes eine Pool-Aufgabe bekommt -- samt dem Kommentar daneben: „Ohne diese Zeile blieb eine Bewerbung auf ,beworben' stehen, nachdem jemand anders die Aufgabe bekommen hat." Derselbe Fall, ein anderer Ausloeser, dieselbe Behandlung. ZWEI WEGE FUEHREN IN DEN ENDZUSTAND -- erledigen und abbrechen. Beide rufen jetzt dieselbe Funktion; nur einen zu bedienen waere die Haelfte, die man spaeter sucht. Der SATZ ist verschieden: „abgebrochen" ist nicht „erledigt", und wer gewartet hat, soll den Unterschied lesen koennen. KEIN `entschieden_von`. Niemand hat entschieden, die Frage hat sich erledigt. Dadurch faellt die Zeile auch aus der Absagen-Uebersicht von gestern heraus (die fragt `entschieden_von IS NOT NULL`) -- richtig, es ist keine Absage an diesen Menschen. KEINE BENACHRICHTIGUNG. „Deine Bewerbung: diesmal nicht" waere falsch -- es hat niemand nein gesagt. Der Satz steht an der Zeile. Wenn Filipe hier doch eine Meldung will, ist es eine eigene Art mit eigenem Wortlaut, kein Anhaengsel an die bestehende. GEPRUEFT -- pruef-bewerbung-aufgaben 163/0 (9 neue): bewirbt sich -> „beworben" Aufgabe erledigt -> faellt weg, mit Satz, ohne Entscheider Aufgabe abgebrochen -> ebenso, mit anderem Satz Aufgabe noch offen -> Bewerbung bleibt <- die Gegenprobe Ohne die letzte Zeile hiesse „faellt weg" womoeglich nur, dass jede Bewerbung wegfaellt. Ein eigener Messfehler unterwegs: Mein Lesehelfer fragte `/api/aufgaben/:id` und bekam `undefined` -- die Antwort dort hat eine andere Form. Vier Pruefungen waren rot, waehrend der Mechanismus im Protokoll nachweislich lief. Jetzt ueber die Liste, die in dieser Datei erprobt ist. Die eine vorhandene Zeile wird nachgetragen; auf einer Kopie der echten Datenbank durchgespielt (danach 0 offene Bewerbungen auf durchgelaufenen Aufgaben, integrity_check ok). pruef-zuteilung, pruef-aufgabenbrett, pruef-zwischenspeicher. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d4a3e54a72 |
Aufgaben: dauerhafte Aufgaben, die nicht abgehakt werden
VanVan im Support: „Man kann bei den Aufgaben, wenn man sie verteilt, ob selbst erstellt oder über die Vorlage noch nicht festlegen, dass die Aufgabe dauerhaft sein soll und somit nicht vom Modi in den Status erledigt gesetzt werden kann." Nachgesehen: Das Wort kam im Aufgabenmodul kein einziges Mal vor. Es war keine vergessene Zeile, es fehlte ganz. WAS EINE DAUERHAFTE AUFGABE IST: keine, die man abarbeitet, sondern eine, die man TUT. „Neue begruessen" ist nicht fertig, wenn man es einmal gemacht hat. ZWEI FOLGEN, und die zweite faellt leicht durchs Raster 1. Der Zugeteilte kann sie nicht auf „erledigt" setzen. Die Sperre steht im SERVER -- ein fehlender Knopf ist eine Bitte, abgelehnt wird an der Route. „Ich fange an" bleibt erlaubt: Auch eine stehende Aufgabe hat einen Anfang. 2. SIE HAT KEINE FRIST. Eine dauerhafte Aufgabe mit Frist waere ab dem naechsten Tag fuer immer ueberfaellig -- und eine Warnung, die immer kommt, ist keine mehr. Die Frist wird GELOESCHT, nicht ignoriert: Ein Datum, das dasteht und nicht gilt, ist schlimmer als keins. WER DARF DAS SETZEN: nur, wer verteilt. Koennte der Zugeteilte seine eigene Aufgabe dauerhaft machen, waere das eine Ausrede; koennte er es zuruecknehmen, waere die Sperre ein Knopf weiter offen. Beides nachgemessen. UND SIE LAESST SICH BEENDEN. Eine Pflicht, die niemand mehr beenden kann, waere eine Falle statt einer Regel. DREI STELLEN, KEINE VIERTE: das Anlegeformular auf „Aufgaben", das auf „Eure Aufgaben" (dort wird verteilt) und das Bearbeiten-Feld. Ueber das letzte laeuft VanVans „oder ueber die Vorlage" -- eine Vorlagen-Aufgabe entsteht ohne Formular, ein Schalter im Vorlagenbrett waere eine vierte Stelle fuer dieselbe Frage. An der Karte steht die Marke fuer ALLE, nicht nur fuer den Zugeteilten: Wer sie ansieht, soll wissen, warum dort kein „Fertig" steht. Ein fehlender Knopf ohne Erklaerung liest sich wie ein Fehler. GEPRUEFT pruef-bewerbung-aufgaben 154/0 (10 neue) mit vier Gegenproben: eine GEWOEHNLICHE Aufgabe laesst sich sehr wohl abhaken (sonst hiesse 409 nur, dass niemand je etwas abhaken kann), „Ich fange an" geht weiterhin, der Zugeteilte setzt und nimmt „dauerhaft" nicht, und nach dem Beenden durch die Leitung geht das Abhaken wieder. ZWEI EIGENE FEHLER, beide von Pruefungen gefunden * Ein BACKTICK in einem Kommentar -- mitten in einem Template-String (`SPALTEN`). Er hat ihn beendet, die Datei war syntaktisch kaputt. Dieselbe Familie wie die deutsche Anfuehrung in einem Anfuehrungsstring: ein Zeichen, das in der Umgebung etwas bedeutet. * `toISOString().slice(0,10)` fuer „morgen" -- pruef-struktur hat es noch am selben Abend gefunden. Zwischen 00:00 und 02:00 liegt der UTC-Tag noch auf gestern; die Pruefung haette nachts falsch angeschlagen. Jetzt ueber `tagLokal()`. Und einer, den nur die Messung zeigen konnte: `holen()` in workspace-zuteilung liest die Aufgabe mit einer eigenen, kurzen Spaltenliste. Ohne `dauerhaft` darin fragte die Sperre `a.dauerhaft` und bekam `undefined` -- sie war still wirkungslos, und im Quelltext daneben sah alles richtig aus. pruef-aufgabenbrett, pruef-zuteilung, pruef-aufgaben-vorlagen, pruef-entwicklung 79/0, pruef-css-klassen, pruef-deutsche-texte, pruef-struktur, pruef-zwischenspeicher 34/0. Schemaaenderung: ADD COLUMN dauerhaft. Datenbank vorher gesichert und geprueft (integrity_check ok, 12 Aufgaben). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5e26df788b |
Bewerbungen: die Absage bleibt lesbar, und ihr seht, was ihr absagt
VanVan im Support: „Wenn sich ein Modi auf eine Aufgabe bewirbt und
man diese ablehnt, dann bekommt der Modi keine Benachrichtigung
darüber, dass die Aufgabe abgelehnt wurde und sieht somit auch eine
eventuelle Begründung nicht. Außerdem haben auch wir nirgendwo eine
Übersicht, bei wem wir welche Aufgaben schon abgelehnt haben."
GEMESSEN, BEVOR GEBAUT WURDE -- die Pruefungen standen zuerst da und
waren rot:
Frida sieht ihre beantwortete Bewerbung 0
Die Leitung sieht die Absagen 0
DIE URSACHE. `vorlagenBewerbungenFuer` fragt `WHERE zustand =
'beworben'`. Sobald jemand antwortet, faellt die Zeile aus JEDER
Ansicht heraus -- mitsamt der Begruendung, die Filipe am 23.09.
ausdruecklich verlangt hat („mit einem text als notiz"). Der Satz
wird also verlangt, geschrieben und weggesperrt.
Bei einer ZUSAGE fiel das nicht auf: Dort entsteht eine Aufgabe, und
an ihrer Karte steht die Antwort. Bei einer ABSAGE entsteht nichts.
Die Benachrichtigung selbst gab es (`bewerbung_antwort`, vorgabe an,
fuer ja und nein). Sie war nur das EINZIGE -- wer sie wegwischt oder
kein Geraet angemeldet hat, erfuhr nie, warum.
WAS JETZT DASTEHT
* BEIM BEWERBER: „Antwort auf deine Bewerbung" mit dem Ergebnis, dem
Satz und dem Namen dessen, der geantwortet hat. Beide Ausgaenge --
eine Liste, die nur Absagen sammelt, waere eine andere Sache. Nach
14 Tagen verschwindet sie von selbst.
SIE STEHT VOR DEM ZUKLAPPEN. Beim ersten Anlauf lag sie im Koerper
des Vorlagenbretts, und der wird nur gebaut, wenn das Brett
aufgeklappt ist -- zugeklappt ist die Vorgabe. Eine Antwort, die
man erst aufklappen muss, ist wieder keine.
* BEI DER LEITUNG: „Schon abgesagt", 90 Tage, mit der Zahl JE MENSCH
vorn. Das ist VanVans eigentliche Frage („falls sich jemand immer
wieder bewirbt und immer wieder abgelehnt wird"), und die
beantwortet eine Liste von zwanzig Zeilen nicht.
AUS BEIDEN WEGEN -- Vorlage und Aufgabe. Eine Uebersicht, die nur
die Haelfte zeigt, ist schlimmer als keine: „Frida wurde nie
abgelehnt" waere dann eine Auskunft, die stimmt und taeuscht.
ZUGEKLAPPT. Eine Liste von Absagen, die immer offen steht, ist eine
Sammlung von Nein-Sagen ueber Menschen, mit denen man morgen wieder
arbeitet.
KEIN ROT. Eine Absage ist kein Fehler; „diesmal nicht" ist keine
Aussage ueber den Menschen. Gedeckter Bernstein, und ab zwei Malen
faellt die ZAHL auf -- nicht nur die Farbe.
ZWEI EIGENE FELDER UND NICHT `bewerbungen` ERWEITERT. Dort heisst
eine Zeile im Browser „wartet auf Antwort", samt Zurueckziehen-Knopf.
Beantwortete Zeilen hineinzumischen haette bei einer Absage genau das
gezeigt. Ein Feld, dessen Bedeutung sich aendert, bricht seine Leser
lautlos.
`entschieden_von IS NOT NULL` TRENNT DREI DINGE, die alle `abgelehnt`
heissen: die Leitung hat eine Bewerbung abgelehnt (das hier), die
Person hat eine Zuteilung abgelehnt (ihre Entscheidung), und „von
jemand anderem uebernommen" (gar keine Absage).
Haustrennung gilt: `darfSchreibenMit` je Zeile.
GEPRUEFT
pruef-bewerbung-aufgaben 144/0 (weitere 10 Pruefungen plus zwei
Bilder). Die Gegenprobe steht in der Vorgeschichte: Dieselben
Pruefungen waren vor dem Bau rot.
Zwei eigene Messfehler, beide im Text festgehalten: Ich habe zuerst
auf dem AUFGABENbrett gemessen -- der Vorlagenkatalog steht aber auf
„Eure Aufgaben" (`zweig: 'team'`). Und `innerText` liefert den Text
so, wie er DASTEHT: Die Zeile suchte „Diesmal nicht" und fand
„DIESMAL NICHT", weil das Schild `text-transform: uppercase` traegt.
pruef-vorlagen 24/0, pruef-aufgaben-vorlagen, pruef-zuteilung,
pruef-aufgabenbrett, pruef-entwicklung 79/0, pruef-css-klassen,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c933bcd2e0 |
Aufgaben: wer verantwortlich ist, hat auch eine Zuteilung
VanVan im Support: „Wenn ein Modi sich auf eine Aufgabe beworben hat
und die von uns angenommen wurde, dann steht beim Modi unter der
Aufgabe immer noch ich bewerbe mich."
GEMESSEN AN DEN ECHTEN DATEN (lesend, auf einer Kopie):
Aufgaben mit Verantwortlichem: 11
davon OHNE Zuteilungszeile: 8
Darunter Marinas zwei offene Vorlagen-Aufgaben -- genau die zwei
Karten aus ihrem Bildschirmfoto.
DIE URSACHE. `katalogAufgabeAnlegen()` schrieb eine Zeile in
`aufgaben` mit `verantwortlich_id` und KEINE in
`aufgaben_zuteilung`. Das Brett liest aber die Zuteilung, nicht den
Verantwortlichen: Es fand nichts, lieferte `meine_zuteilung: null`,
und die Bedingung im Browser beginnt mit `!mein` -- also bot sie an,
sich auf die eigene Aufgabe zu bewerben.
ES WAR NICHT NUR EIN FALSCHER KNOPF. „Ich fange an" und „Fertig"
haengen an derselben Zeile. Der Mensch bekam eine Karte, auf der er
das Falsche tun konnte und das Richtige nicht.
WARUM DIE VORHANDENE PRUEFUNG ES NICHT FAND: Sie geht den Weg ueber
das AUFGABENbrett -- dort war alles in Ordnung, nachgemessen steht
nach dem Annehmen richtig „Ich fange an | Fertig". VanVans Weg ist
der ueber das VORLAGENbrett, und der endet in einer neu angelegten
Aufgabe. Dieser Weg war nie geprueft.
DREI TEILE
1. `katalogAufgabeAnlegen` legt die Zuteilungszeile mit an. Mit
Zustand: `angenommen`, wenn die Person darum gebeten hat und die
Bitte angenommen wurde; `offen`, wenn die Leitung zutraegt -- dann
steht bei ihr Annehmen/Ablehnen, und das ist richtig, sie hat noch
nicht ja gesagt.
2. Eine Umstellung traegt nach, was schon dasteht. Wiederholbar
(`NOT EXISTS` + `INSERT OR IGNORE`), deshalb bei den Umstellungen
und nicht in einem Skript, das jemand vergisst. Auf einer KOPIE
der echten Datenbank durchgespielt: 8 Zeilen angelegt, danach 0
ohne Zuteilung, `integrity_check ok`. Marinas Karten stehen
danach auf `angenommen`.
3. Ein Riegel im Browser: Auf eine Aufgabe, die mir schon gehoert,
bewirbt man sich nicht. Er faengt jeden weiteren Weg ab, der eine
Aufgabe ohne Zuteilungszeile anlegt -- nicht alle acht kamen aus
der Vorlage.
GEPRUEFT
pruef-bewerbung-aufgaben 126/0 (15 neue: der ganze Vorlagenweg von
der Bewerbung bis zum Knopf auf ihrem Brett). NACHGESTELLT: Ohne die
Zuteilungszeile wird sie rot („und sie hat eine Zuteilungszeile
(undefined)"). pruef-zuteilung, pruef-aufgabenbrett, pruef-vorlagen
24/0, pruef-aufgaben-vorlagen, pruef-struktur, pruef-zwischenspeicher
34/0.
Ein Messfehler unterwegs, im Text festgehalten: Mein neuer Block
bewarb sich auf dieselbe Vorlage wie ein spaeterer Abschnitt und
nahm ihm damit seine -- zehn Pruefungen wurden rot, ohne dass am
Programm etwas falsch war.
Datenbank vor der Umstellung gesichert und geprueft
(integrity_check ok, 12 Aufgaben, 3 Zuteilungen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
077925ab25 |
Dreizehn rote Pruefungen, eine Ursache: openssl steht nicht im PATH
DER BEFUND
Im naechtlichen Lauf standen dreizehn Pruefungen mit derselben Zeile
rot:
[uncaughtException] Error: spawnSync openssl ENOENT
Kein Programmfehler. Die Pruefungen brauchen einen https-Vorbau (der
Sitzungskeks des Hauses ist `secure` und kommt ueber http nicht an),
und dafuer erzeugen sie ein Wegwerf-Zertifikat mit openssl.
GEMESSEN, NICHT VERMUTET
openssl liegt hier: C:\Program Files\Git\mingw64\bin\openssl.exe
C:\Program Files\Git\usr\bin\openssl.exe
im System-PATH steht: C:\Program Files\Git\cmd (nur git.exe)
im Benutzer-PATH: nichts mit Git
Wer aus Git Bash startet, erbt die mingw-Pfade und merkt nie etwas.
Die Aufgabenplanung startet `node.exe` DIREKT, ohne Shell -- und
bekommt sie nicht. Bei mir gruen, nachts rot, und der Grund steht
nicht im Code.
Das Schlimmste daran ist nicht der Ausfall: Dreizehn dauerhaft rote
Zeilen in einer Notiz, die Filipe morgens liest, gewoehnen einem das
Hinsehen ab -- und decken dabei die echten Befunde zu.
DIE REPARATUR
`server/helfer-openssl.mjs` sucht openssl erst im PATH (ohne `where`
oder `which` -- beides sind selbst Programme und koennen genauso
fehlen), danach an den Orten, an denen es auf einem Windows-Rechner
mit Git wirklich liegt.
Dazu `zertifikatBauen(schluessel, zertifikat, host)`. Die acht
Aufrufformen im Haus waren identisch bis auf die Variablennamen
(schl/zert, schluesselDatei/zertDatei, zKey/zCrt, sk/zt, key/crt) --
eine Stelle traegt alle neunundzwanzig. Zwei Tage zuvor war eine
davon um ein `-addext` aermer als die anderen; gemerkt hat es
niemand, weil der Browser den fehlenden Alternativnamen erst bei
einer Weiterleitung anmahnt. Eine Stelle kann nicht von sich selbst
abweichen.
KEIN EINTRAG IN DEN SYSTEM-PATH. `mingw64\bin` enthaelt rund hundert
Programme mit Unix-Namen (`find`, `sort`, `link`), die gleichnamige
Windows-Befehle verdecken. Das fuer eine Pruefung zu aendern haette
an ganz anderen Stellen Fehler verursacht, die niemand hierher
zurueckverfolgt.
GEGENPROBE IN BEIDE RICHTUNGEN, mit dem PATH des Nachtlaufs:
vorher (direkter Aufruf): ABSTURZ: spawnSync openssl ENOENT
nachher (ueber den Helfer): Zertifikat gebaut, 1236 Bytes
Und eine echte Pruefung unter denselben Bedingungen:
PATH ohne mingw64 -> pruef-chat-neu-stelle
63 Pruefungen, 0 Fehler, 0 Abstuerze
Genau diese Datei stand im Nachtlauf mit ENOENT rot.
EINE WACHE DAGEGEN
pruef-struktur prueft ab jetzt, dass niemand openssl wieder direkt
ruft -- der naechste merkt es dort und nicht erst in einem
Nachtlauf, den niemand liest. Drei Gegenproben.
Beim ersten Anlauf schlug sie auf ihre EIGENEN Probetexte an: Sie
liest alle Serverdateien, und dazu gehoert sie selbst. Die Texte
werden jetzt zusammengesetzt. Derselbe Selbsttreffer ist mir heute
schon zweimal passiert.
DER DRITTE AUSGANG BLEIBT, WO ER HINGEHOERT
`helfer-kachel-echtfarbe.mjs` faengt den Fehler weiterhin ab und
meldet `moeglich: false` mit Grund, statt abzubrechen. Eine
Sicherung abzuschaffen, weil ihr Anlass gerade behoben ist, ist der
Anfang des naechsten stillen Fehlschlags.
NEBENBEI: pruef-community-sicht
Sie war rot mit "ZU VIEL: reaktion.html" -- mein eigener Rueckstand
vom 28.09. Die Reaction steht als Kachel im Community-Bereich; die
Liste war nicht nachgezogen. Jetzt 10 / 0.
Die Liste bleibt bewusst von Hand gepflegt: Sie ist eine ABSICHT,
keine Ableitung. Aus rechte.js gelesen verglichen sich zwei Kopien
derselben Quelle -- immer gruen, nie ein Beweis.
GEPRUEFT
pruef-struktur ALLES IN ORDNUNG (mit der neuen Wache)
pruef-community-sicht 10 / 0
pruef-chat-neu-stelle 63 / 0 (mit dem PATH des Nachtlaufs)
pruef-notizen, -teamlage-karten, -werdegang: EXIT 0, keine Abstuerze
mess-quer EXIT 0
29 Dateien: node --check auf allen, kein direkter Aufruf mehr
|
||
|
DogFatherGitandClaude Opus 5
|
8bf2f440d0 |
Bewerbungen der Modis bekommen eine eigene Spalte im Aufgabenbrett
Filipe: "ich will in dieser seite auch eine eigene kategorie fuer die
aufgaben wo die modis sich selbst bewerben. ich will dass man die
getrennt sieht. mach es richtig uebersichtlich."
WO SIE VORHER STANDEN, und warum das nicht reichte: nur auf dem
Vorlagenbrett, an der jeweiligen Karte. Das ist der richtige Ort zum
ENTSCHEIDEN -- man liest Aufgabe und Name nebeneinander. Es ist der
falsche Ort zum SEHEN: Wer morgens das Aufgabenbrett oeffnet, sieht
nicht, dass drei Leute auf eine Antwort warten, und das Vorlagenbrett
ist eine Seite weiter. Fuer den Modi gab es ueberhaupt keine Stelle,
an der stand "dein Wunsch ist angekommen".
DIE SPALTE STEHT GANZ VORN. Sie ist die einzige, in der jemand auf eine
ANTWORT wartet -- alle anderen zeigen Arbeit, die laeuft. Und sie
VERSCHWINDET, wenn nichts wartet: Eine leere Spalte "Bewerbungen"
stuende 360 Tage im Jahr im Weg, um an fuenf Tagen etwas zu sagen. Die
vier festen Spalten haben auch leer eine Aussage ("hier landet, was
fertig ist"); diese nicht.
WAS AUF DER KARTE STEHT: der TITEL der Vorlage (nicht ihr Schluessel),
wer sie uebernehmen moechte, und sein eigener Satz dazu -- als Zitat
gesetzt, mit Strich davor. Er gehoert ihm, nicht dem Brett. Ohne ihn
entscheidet man ueber einen Namen.
DER TITEL WIRD NACHGESCHLAGEN, NICHT MITGESPEICHERT. Er gehoert dem
Katalog; stuende er in der Bewerbungszeile, gaebe es zwei Wahrheiten,
und die aeltere gewinnt still, sobald jemand eine Vorlage umbenennt.
EIN EIGENER, KLEINER WEG statt eines Mitschleppens:
`/workspace/api/vorlagen/bewerbungen` liefert nur die Bewerbungen --
nicht den ganzen Katalog, der an `/workspace/api/vorlagen` haengt. Das
Brett zeichnet sich bei jedem Statuswechsel neu; der Katalog ist um ein
Vielfaches groesser als die Handvoll Bewerbungen.
WER ENTSCHEIDEN DARF, SAGT DER SERVER (`darf_entscheiden`) -- nicht der
Rollenname im Browser. `assets/js` bekommt jeder, der die Seite
oeffnet, und ein Rollenvergleich dort ist in diesem Haus allein diese
Woche dreimal veraltet. Bis die Antwort da ist, gilt `false`: lieber
einen Knopf zu spaet zeigen als einen, der eine Absage holt.
DIE FARBE IST NEU IM BRETT. Die vier vorhandenen stehen fuer einen
Arbeitsstand (grau, blau, gelb, gruen); hier wartet niemand auf Arbeit,
sondern auf eine Entscheidung. Kein Rot ("kaputt"), kein Gelb (heisst
schon "zur Freigabe") -- Violett, das im Chat seit gestern fuer "an
dich gerichtet" steht. Eine Sprache im Haus.
Geprueft: pruef-bewerbung-aufgaben 101 -> 111 Punkte. Darunter die drei
Gegenproben, ohne die "die Spalte ist da" nichts bewiese: ohne
Bewerbung gibt es sie NICHT, der Modi bekommt KEINE
Entscheidungsknoepfe (sondern "wartet auf Antwort"), und die Spalte
steht wirklich an erster Stelle. Dazu pruef-aufgabenbrett und
pruef-vorlagen (24), beide unveraendert gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
803750edbc |
Aufgaben verteilen: der Knopf ist nie mehr tot, und die Bewerbung steht im Formular
screen1 -- „dogfather, die rechte hand und die linke hand sollen immer
noch aufgaben werden teilen können plus die option dass die modis sich
für aufgaben bewerben können. weil gerade hängt das und weiß nicht
wieso."
WAS WIRKLICH LOS WAR -- gemessen, nicht geraten
Auf entwicklung.html stand oben „Aufgabe verteilen · Wähl LINKS
jemanden aus", und der Knopf war so lange abgeschaltet. Im Browser
nachgemessen (1420 px, als DogFather):
Band oben 284 px, linke Kante 130 px
Personenwahl oben 490 px, linke Kante 130 px
-> UNTER dem Band, 127 px darunter, gleiche linke Kante
Links war nichts. Wer der Anweisung folgte, schaute auf eine leere
Fläche und hatte einen Knopf, der nicht ging. Das Recht selbst war die
ganze Zeit richtig: `darfAufgabenVerteilen` = Leitung oder Hand, also
DogFather, rechte Hand UND linke Hand -- alle drei mit
`darf_verteilen: true` gemessen.
Kurz: Die Regel stimmte, der Weg dorthin nicht.
WAS JETZT ANDERS IST
1. DER KNOPF IST IMMER BENUTZBAR. Er öffnet das Formular, auch ohne
vorherige Auswahl.
2. DIE FRAGE „für wen" STEHT IM FORMULAR, als erste Zeile, mit allen
Personen zur Wahl. Wer unten eine Kachel angeklickt hat, findet sie
angehakt wieder -- beide Wege führen zum selben Ziel.
3. EINE LISTE STATT ZWEIER. „Noch jemanden dazunehmen" ist weg. Es
waren zwei Bedienungen für dieselbe Frage -- und die
Bewerbungs-Option steckte ausgerechnet in der zugeklappten
zweiten: Sie war nur zu finden, wenn man erst aufklappte UND dort
jemanden ankreuzte. Eine Möglichkeit, die man nicht findet, gibt es
nicht.
4. DIE BEWERBUNG STEHT DA, sobald zwei Leute angehakt sind: „Wer
zuerst Zeit hat, übernimmt. Sie bewerben sich, du nimmst an oder
lehnst ab."
ZWEI FEHLER, DIE DABEI AUFFIELEN
* Nach dem Anlegen wurde `fuerPerson` auf null gesetzt und DANACH
`aufgabenZeigen(fuerPerson, …)` aufgerufen -- die Liste, die zeigen
soll, was gerade entstanden ist, blendete sich damit aus. Die Namen
werden jetzt festgehalten, bevor `reset()` sie abräumt.
* Die Bestätigung sagte immer „steht jetzt bei ihm" -- `fuerName` wird
nur beim Klick auf eine Kachel gefüllt. Sie sagt jetzt, was wirklich
passiert ist, und bei einem Pool, dass eine Bewerbung kommt.
* `e-mehr-art` heisst `e-art`: Der Name sagte „gehört zu ‚noch
jemand'", und das gibt es nicht mehr. Dieselbe Sorte Falle wie
`tperson__namen` heute Nachmittag.
DIE PRÜFUNG HATTE MEINEN FEHLER FESTGESCHRIEBEN
`pruef-bewerbung-aufgaben.mjs` enthielt wörtlich:
ok(vorher.aus === true,
"und ist aus, solange niemand gewaehlt ist");
Sie lief, sie war grün, und sie hat den toten Knopf verteidigt. Das
ist die unangenehmste Sorte: nicht übersprungen, nicht kaputt --
sondern eine Bestätigung meines Entwurfs statt der Sache. Jetzt wird
das Gegenteil verlangt.
Dazu zwei neue Abschnitte (84 -> 101 Prüfungen, 0 Fehler):
6b verteilen OHNE vorherige Auswahl, als Pool, samt Nachweis am
Server (verteilart=pool, zwei Leute darin) und der Meldung, die
nicht „bei ihm" sagen darf
6c alle drei Rollen am Bildschirm: DogFather, rechte Hand, linke
Hand -- mit Gegenprobe, dass ein Modi das Band NICHT sieht
EIGENER MESSFEHLER, offen notiert: Mein erster Versuch, die Bewerbung
nachzustellen, meldete „kein Abruf, nichts passiert". Der Knopf öffnet
eine Rückfrage, und die hatte ich nicht beantwortet. Die Bewerbung war
nie kaputt -- meine Messung war es. Erst der zweite Anlauf zeigte den
ganzen Weg: POST /api/aufgaben/1/bewerben -> {"ok":true,"zustand":"beworben"}.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3b76a9aab5 |
screen1 + A5 + B6: „wer zuerst Zeit hat" gilt wieder, und Aufgaben entstehen dort, wo die Person steht
DREI SACHEN, EIN ZUSAMMENHANG.
--- screen1 --------------------------------------------------------
Filipe zu meinem eigenen Satz „wer zuerst Zeit hat — genau das geht ja
nicht mehr": „falls das nicht mehr geht mach das es geht wenn es wieder
geht ist alles gut."
Er hat recht, und ich hatte zu schnell aufgegeben. „Wer zuerst Zeit
hat" muss nicht heissen, dass man sich selbst bedient -- es kann
genauso heissen, dass die ERSTE BEWERBUNG zuerst drankommt. Damit gilt
beides: Die Leitung entscheidet (sein Wunsch von vorhin), und wer
schnell ist, hat den Vorteil (sein Wunsch von eben).
Die Bewerbungen werden jetzt nach EINGANG sortiert, nicht nach Namen
-- die Abfrage sortiert sonst alphabetisch, und dann haette nicht der
Schnelle den Vorteil, sondern Frida. Der Erste bekommt die Marke
„zuerst da" (nur bei mehr als einer -- sonst ist es keine Auskunft,
sondern Fuellwerk).
Geprueft mit Absicht gegen das Alphabet: Nele bewirbt sich zuerst und
steht vorn, obwohl Frida im Alphabet vor ihr kaeme.
--- B6: der Knopf auf dem Aufgabenbrett ----------------------------
Filipe: „dieser button kann da jetzt doch endlich verschwinden, auf
dieser seite sollen ja keine aufgaben mehr verteilt werden."
ER HAT DABEI AUF DEN TEAM-DOGI-BILDSCHIRM GESEHEN, und das ist der
Unterschied zwischen „weg damit" und „weg damit, aber gemessen":
Rolle/Haus aufgaben.html entwicklung.html darfAnlegen
manager/agentur ja NEIN ja
creator/agentur ja NEIN ja
scout/agentur ja NEIN ja
spicy/agentur ja NEIN ja
Haette ich den Knopf einfach entfernt, koennten vier Rollen gar keine
Aufgabe mehr anlegen. Der Server nennt deshalb den ORT, und er leitet
ihn aus den KACHELN der Person ab -- nicht aus dem Seitenrecht (dann
haette DogFather auf der Agenturadresse den Knopf verloren, denn
oeffnen darf er die Seite, nur hat er dort keine Kachel dorthin) und
schon gar nicht aus dem Haus.
--- A5: anlegen, wo die Person steht -------------------------------
Filipe: „dieser buttion da soll nicht einen zu der seite aufgaben
fuehren sondern da in dieser seite die aufgaben erstellen und vergeben
koennen. plus man soll die aufgaben hier in dieser seite auch sehen."
Der Knopf war ein Link auf `aufgaben.html?neu=1`. Jetzt oeffnet er ein
Formular an Ort und Stelle. DREI FELDER, NICHT ZWOELF: Wer hier steht,
hat die Person schon gewaehlt; was fehlt, ist was, bis wann und ob
noch jemand mitmacht. Das grosse Formular auf dem Brett bleibt fuer
den Fall, dass man eine Aufgabe fuer irgendwen irgendwo anlegt -- zwei
vollstaendige Masken fuer dieselbe Sache waeren zwei Gelegenheiten,
eine davon zu vergessen.
Dazu die Aufgaben der gewaehlten Person, auf derselben Seite. Sie
kommen beim Auswaehlen und nicht auf Knopfdruck: Wer jemanden
durchgeht, will wissen, was bei ihm liegt.
Ohne Person ist der Knopf AUS statt weg -- sonst springt die Seite beim
Auswaehlen -- und der Satz daneben sagt, was fehlt.
Gemeldet wird, was der Server WIRKLICH gesetzt hat: `zuteilen` kann
eine Person weglassen (gesperrter Zugang). Wer das verschweigt, laesst
jemanden im Glauben, er habe drei Leute eingetragen.
--- EIN FUND AUF DEM EIGENEN BILDSCHIRMFOTO ------------------------
Die Bestaetigung „Clips vom Samstag schneiden steht jetzt bei Rieke."
stand in WARNROT -- `melde` schreibt immer in denselben Absatz, und
der heisst `.fehler`. Nicht schlimm und genau deshalb heimtueckisch:
Wer Bestaetigungen in Rot liest, sucht den Fehler, und wer sich daran
gewoehnt, ueberliest die echte Warnung. `melde` kennt jetzt eine gute
Nachricht; die Vorgabe bleibt „Fehler", damit die neun vorhandenen
Aufrufe nicht stillschweigend umgefaerbt werden.
GEPRUEFT
pruef-bewerbung-aufgaben 84/0 (von 66) -- neu: die Reihenfolge nach
Eingang mit Gegenprobe gegen das Alphabet, und ein Abschnitt, der A5
und B6 am echten Bildschirm durchspielt (Knopf weg auf dem Brett, kein
Link mehr auf der Entwicklungsseite, Formular oeffnet dort, Aufgabe
steht sofort in der Liste darunter UND wirklich in der Liste des
Servers, Bestaetigung als gute Nachricht gekennzeichnet).
Gruen: pruef-entwicklung, pruef-aufgabenbrett, pruef-css-klassen,
pruef-formulare, pruef-struktur.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
43545e4acd |
A4: Bewerben statt selbst nehmen
Filipe, 22.09.2026: „die modis und linke hand sollen da nichts
uebernehmen koennen von aufgaben, ueberhaupt ueberall sollen die keine
aufgaben selber uebernehmen die ihnen nicht zugetragen sind. ich will
dass die sich fuer aufgaben bewerben koennen aber die rechte hand oder
dogfather muessen annehmen oder ablehnen koennen und das mit einem
kommentar als moeglichkeit sogar noch zum hinzufuegen."
ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS -- und das war der Schluessel:
verteilen eine Aufgabe an ANDERE geben
entscheiden bestimmen, wer sie am Ende macht
Sein Satz vom selben Tag („rechte hand linke hand und dogfather ...
koennen alle verteilen") widerspricht dem nicht, er beantwortet die
erste Frage. Die linke Hand verteilt, entscheidet aber nicht -- sie
bewirbt sich wie ein Modi. `entscheidetUeberAufgaben` steht neben
`darfAufgabenVerteilen`, und drei Stellen fragen ab jetzt dieselbe
Funktion.
DAS VERBOT HATTE DREI TUEREN, und die zweite und dritte waren beim
Planen nicht zu sehen:
1. aus dem Pool „uebernehmen" -- die offensichtliche
2. beim Pool „annehmen" -- dasselbe unter anderem Namen: Wer
zusagt, nimmt sie den anderen weg.
Bei „einzeln"/„mehrere" bleibt es
erlaubt -- dort wurde sie ihm
ZUGETRAGEN, und genau das Wort
steht in seinem Satz.
3. beim Verteilen sich selbst eintragen -- die linke Hand darf
verteilen, haette sich also selbst
nehmen koennen. Abgelehnt statt
still gefiltert: Wer sich eintraegt
und sich danach nicht findet, sucht
den Fehler bei sich.
EIN FUND, OHNE DEN A4 GAR NICHT FUNKTIONIERT HAETTE
Die rechte Hand soll entscheiden -- und sah die Aufgabe nicht, um die
es ging. Gemessen an einer Pool-Aufgabe, die DogFather fuer zwei Modis
angelegt hat:
DogFather sieht sie 1 Bewerbung
Modi sieht sie 1 Bewerbung
rechte Hand SIEHT SIE NICHT (Liste leer)
Ihre Sichtregel sammelte Menschen mit einer TEAM_DOGI_ROLLE und fragte,
ob einer als Creator, Verantwortlicher oder Ersteller eingetragen ist.
Bei einer Pool-Aufgabe bleibt `verantwortlich_id` leer (das ist ihr
Sinn), und der Ersteller war DogFather -- der in dieser Liste nicht
steht. Alle drei Bedingungen liefen ins Leere.
Auf der Adresse von Team Dogi sehen die Haende jetzt alles. Das ist
zugleich sein Satz „sehen alle aufgaben". Die Haustrennung bleibt:
`sichtbar()` haengt fuer crew weiterhin `AND ohneAgentur(...)` davor.
WIE DIE BEWERBUNG GEBAUT IST
Kein zweiter Tisch, sondern ein weiterer Zustand derselben Zeile
(`beworben`). Die Frage „wie steht diese Aufgabe bei DIESEM Menschen"
wird dort schon beantwortet; eine zweite Tabelle haette zwei Wahrheiten
ueber dieselbe Beziehung.
Die Worte der Person (`grund`) und der Kommentar der Leitung
(`entscheid_text`) stehen in ZWEI Feldern. In dasselbe waere bequemer
und wuerde die Frage mit der Antwort ueberschreiben -- danach wuesste
niemand mehr, worum jemand gebeten hat. Dasselbe gilt, wenn eine
Bewerbung wegfaellt, weil jemand anders die Aufgabe bekommt: Der
Hinweis kommt in das Feld der Leitung, ihre Worte bleiben stehen.
Der Kommentar ist FREIWILLIG. Die Begruendung beim Ablehnen einer
zugeteilten Aufgabe bleibt Pflicht -- dort sagt jemand ab, der gefragt
wurde. Hier bittet jemand; ein „bitte" braucht keine Begruendung.
Filipes Wort ist „als moeglichkeit".
Die CHECK-Regel wurde ueber `checkListeErweitern` erweitert -- den Weg,
der seit dem 09.09. an einer Stelle steht, mit Sicherung vorher,
Spaltenliste aus PRAGMA und Indizes, die mitgehen.
UND EIN SATZ, DER NICHT MEHR STIMMTE
„Frei fuer 3 Leute — wer zuerst Zeit hat" war die Beschreibung des
Pools, solange sich jeder selbst bedienen durfte. Er sagt jetzt jedem,
was FUER IHN gilt.
GEPRUEFT
Neu: server/pruef-bewerbung-aufgaben.mjs, 66/0 -- die Regel selbst,
alle drei Tueren, der erlaubte Weg, die zwei Felder, das Zurueckziehen,
und ein Abschnitt am echten Bildschirm (ein Modi sieht „Ich bewerbe
mich" statt „Ich uebernehme das"; die rechte Hand sieht die Bewerbung
mit Annehmen und Ablehnen; die Bewerberin sieht KEINEN Block zum
Entscheiden -- sonst waere das Verbot einen Knopf weiter offen).
pruef-zuteilung auf die neue Regel umgestellt (sie hielt „Bea
uebernimmt sie" fest und wurde zu Recht rot) -- misst jetzt denselben
Effekt ueber den neuen Weg. Dazu gruen: pruef-aufgabenbrett,
pruef-meldungen, pruef-sicht, pruef-css-klassen.
ALTLAST, nicht von hier: pruef-rollen meldet einen Fehler an der
Kachel „Zu Team Dogi" (absolute Adresse). Mit `git stash` nachgemessen
-- vorher und nachher identisch.
Co-Authored-By: Claude Opus 5 <[email protected]>
|