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]>
This commit is contained in:
2026-10-02 15:11:35 +02:00
co-authored by Claude Opus 5
parent 664b799568
commit 731537b682
51 changed files with 1087 additions and 710 deletions
+184 -9
View File
@@ -300,8 +300,163 @@ melde("\n=== Fertig machen und bewerten ===");
ok(zuFrueh.code === 409 && zuFrueh.json?.fehler === "noch_nicht_erledigt",
`vor dem Fertigwerden wird nicht bewertet (HTTP ${zuFrueh.code})`);
/* ===================================================================
DER STATUS DER AUFGABE ZIEHT DIE ZUTEILUNG MIT (02.10.2026)
VanVan im Support: „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."
Sie hat ZWEI Zustaende gefunden, die nebeneinander liefen:
aufgaben.status offen · arbeit · review · erledigt
aufgaben_zuteilung.zustand angenommen · arbeit · erledigt
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.
Die zwei Knoepfe sind weg (ihr Wunsch). Damit das keine stille
Verschlechterung ist -- die ZAEHLER einer Person lesen die
Zuteilung, nicht die Aufgabe --, folgt die Zuteilung jetzt dem
Status. Hier wird beides zusammen gemessen: der Zustand UND die
Zahl, die daraus entsteht.
=================================================================== */
/* UEBER DIE LISTE, nicht ueber einen Einzelabruf: Den gibt es nicht,
und `meine_zuteilung` haengt genau dort dran. Mein erster Anlauf
fragte `/aufgaben/<id>` und bekam ueberall `null` -- die Pruefung
war rot, und der Fehler war meiner. */
const standVon = async (keks, id) => {
const r = await rufe("/workspace/api/aufgaben", { keks });
const a = (r.json?.aufgaben || []).find((x) => x.id === id);
return a?.meine_zuteilung?.zustand ?? null;
};
const zaehlerVon = async (keks) =>
(await rufe("/workspace/api/aufgaben/resuemee", { keks })).json || {};
const vorher = await standVon(bea, idPool);
const zVorher = await zaehlerVon(bea);
ok(vorher === "angenommen",
`Bea hat die Aufgabe angenommen, mehr nicht (${vorher})`);
const aufArbeit = await rufe(`/workspace/api/aufgaben/${idPool}`, { method: "PATCH",
keks: chef, body: { status: "arbeit" } });
ok(aufArbeit.code === 200, `die Leitung setzt die AUFGABE auf "arbeit" (${aufArbeit.code})`);
const nachArbeit = await standVon(bea, idPool);
ok(nachArbeit === "arbeit",
` und Beas Zuteilung geht mit (${vorher} -> ${nachArbeit})`);
const zArbeit = await zaehlerVon(bea);
ok(zArbeit.arbeit > (zVorher.arbeit || 0),
` ihr Zaehler „in Arbeit" steigt (${zVorher.arbeit || 0} -> ${zArbeit.arbeit})`);
/* ZURUECK AUF OFFEN HEISST NICHT „NICHT ZUGESAGT". Das ist die eine
Abweichung von der Zuordnung, und sie wird hier gemessen: Wer
zugesagt hat, faellt nicht auf „offen" zurueck. */
const zurueck = await rufe(`/workspace/api/aufgaben/${idPool}`, { method: "PATCH",
keks: chef, body: { status: "offen" } });
ok(zurueck.code === 200, `zurueck auf "offen" (${zurueck.code})`);
const nachZurueck = await standVon(bea, idPool);
ok(nachZurueck === "angenommen",
` Beas Zusage bleibt bestehen — „angenommen", nicht „offen" (${nachZurueck})`);
/* UND EINE BEWERBUNG WIRD NICHT UEBERSCHRIEBEN. Wer sich nur
beworben hat, hat nicht zugesagt -- ein Statuswechsel darf daraus
keine Zusage machen. */
const vorBew = await rufe(`/workspace/api/aufgaben/${idPool}/bewerben`,
{ method: "POST", keks: cem, body: {} });
const bewStand = await standVon(cem, idPool);
await rufe(`/workspace/api/aufgaben/${idPool}`, { method: "PATCH",
keks: chef, body: { status: "arbeit" } });
const bewNachher = await standVon(cem, idPool);
ok(bewStand === bewNachher,
`eine Bewerbung bleibt eine Bewerbung (${bewStand} -> ${bewNachher},`
+ ` HTTP ${vorBew.code})`);
/* ===================================================================
DIE SCHMALE TUER -- UND IHRE GRENZEN (02.10.2026)
Damit VanVans Satz stimmt („es gibt darüber ja den button
starten"), darf jetzt auch jemand den STATUS setzen, der die
Aufgabe nur HAT. Vorher konnte das nur, wer sie umschreiben
durfte -- eine Modi sah deshalb gar keinen Knopf (gemessen:
„Schritt-Knoepfe: []").
EIN ERWEITERTES RECHT BRAUCHT GEGENPROBEN, sonst ist es ein Loch
mit Begruendung. Drei Stueck:
· Der Status ja.
· Alles andere nein -- auch nicht in derselben Anfrage.
· Und wer sich nur beworben hat, gar nichts.
=================================================================== */
/* DER REINE FALL WIRD GESUCHT, NICHT GERATEN.
Mein erster Anlauf nahm Bea und die Pool-Aufgabe -- und die
Gegenprobe wurde rot: Bea darf sie ohnehin umschreiben, weil das
Uebernehmen aus dem Pool sie verantwortlich macht. Sie ist also
der falsche Zeuge; an ihr laesst sich ueber die neue, schmale
Tuer gar nichts zeigen.
Gebraucht wird jemand, der eine Aufgabe NUR ueber die Zuteilung
hat: `meine_zuteilung` gesetzt, `darf_aendern` falsch. Genau das
wird hier gesucht -- eine fest hingeschriebene Nummer waere die
naechste, die beim naechsten Umbau nicht mehr stimmt. */
const annaListe = await rufe("/workspace/api/aufgaben", { keks: anna });
const rein = (annaListe.json?.aufgaben || []).find((x) =>
x.darf_aendern === false
&& ["angenommen", "arbeit"].includes(x.meine_zuteilung?.zustand));
ok(!!rein,
`Anna hat eine Aufgabe, die ihr NUR zugeteilt ist (#${rein?.id},`
+ ` zustand ${rein?.meine_zuteilung?.zustand}, darf_aendern ${rein?.darf_aendern})`);
ok(rein?.darf_status === true,
` und der Server gibt ihr trotzdem das Statusrecht (darf_status ${rein?.darf_status})`);
const selbstStatus = await rufe(`/workspace/api/aufgaben/${rein?.id}`,
{ method: "PATCH", keks: anna, body: { status: "arbeit" } });
ok(selbstStatus.code === 200,
`sie setzt den Status ihrer Aufgabe (HTTP ${selbstStatus.code})`);
const auchTitel = await rufe(`/workspace/api/aufgaben/${rein?.id}`,
{ method: "PATCH", keks: anna, body: { status: "offen", titel: "Umbenannt" } });
ok(auchTitel.code === 403,
`Gegenprobe: mit einem zweiten Feld kommt sie nicht durch (${auchTitel.code})`
+ " — sonst waere die schmale Tuer die breite mit Zusatzfeld");
const nurTitel = await rufe(`/workspace/api/aufgaben/${rein?.id}`,
{ method: "PATCH", keks: anna, body: { titel: "Umbenannt" } });
ok(nurTitel.code === 403,
` und umschreiben darf sie gar nicht (${nurTitel.code})`);
const heisstNoch = await rufe("/workspace/api/aufgaben", { keks: chef });
const titelJetzt = (heisstNoch.json?.aufgaben || [])
.find((x) => x.id === rein?.id)?.titel || "";
ok(titelJetzt !== "Umbenannt",
` der Titel steht unveraendert da („${titelJetzt}")`);
const fremderStatus = await rufe(`/workspace/api/aufgaben/${rein?.id}`,
{ method: "PATCH", keks: cem, body: { status: "erledigt" } });
ok(fremderStatus.code === 403 || fremderStatus.code === 404,
` und wer sie nicht hat, setzt auch keinen Status (${fremderStatus.code})`);
/* ZURUECKRAEUMEN -- und die Rueckfahrt ist selbst eine Messung.
Dieser Abschnitt hat Annas Aufgabe auf „arbeit" gestellt. Ein
spaeterer Abschnitt zaehlt ihre „angenommen" und wurde dadurch
rot: ein Befund, den ich selbst erzeugt habe. Eine Pruefung, die
den Bestand fuer die naechste veraendert, misst ab da etwas
anderes als sie glaubt.
Das Zuruecksetzen beweist dabei die zweite Haelfte der Regel:
Wer zugesagt hat, faellt beim Zurueckdrehen auf „angenommen" --
nicht auf „offen". */
await rufe(`/workspace/api/aufgaben/${rein?.id}`,
{ method: "PATCH", keks: chef, body: { status: "offen" } });
const wiederDa = await standVon(anna, rein?.id);
ok(wiederDa === "angenommen",
` zurueckgedreht steht Anna wieder auf „angenommen" (${wiederDa})`);
const arbeit = await rufe(`/workspace/api/aufgaben/${idPool}/mein-stand`, { method: "POST", keks: bea,
body: { zustand: "arbeit" } });
/* DER WEG BLEIBT BESTEHEN, auch ohne Knopf: Er ist die Schranke
fuer den, der die Schnittstelle direkt anspricht. */
ok(arbeit.code === 200, `Bea setzt "in Bearbeitung" (HTTP ${arbeit.code})`);
const fertig = await rufe(`/workspace/api/aufgaben/${idPool}/mein-stand`, { method: "POST", keks: bea,
body: { zustand: "erledigt" } });
@@ -573,15 +728,35 @@ melde("\n=== Am echten Bildschirm ===");
ok(band && band.zahlen.length >= 3,
`mit Zahlen (${(band?.zahlen || []).join(" · ")})`);
/* DER KERN DER OBERFLAECHE: Der Knopf, mit dem sie annimmt. */
const knopf = await pAnna.seite.evaluate(() => {
const k = [...document.querySelectorAll(".z-karte .knopf")]
.map((b) => b.textContent.trim());
return k;
});
ok(knopf.length > 0, `an ihren Karten stehen Knoepfe (${knopf.join(", ")})`);
ok(knopf.includes("Fertig") || knopf.includes("Ich fange an") || knopf.includes("Annehmen"),
"und darunter einer, der sie weiterbringt");
/* ==== KOMMT SIE WEITER? (neu gemessen 02.10.2026) =============
Hier stand: „an ihren Karten stehen Knoepfe" und darunter eine
ODER-Bedingung auf „Fertig", „Ich fange an" oder „Annehmen".
Seit die zwei Knoepfe weg sind (VanVans Meldung), trifft keiner
der ersten beiden mehr zu -- und die Pruefung wurde rot. Das war
richtig von ihr: Sie hat gefragt, ob ein Modi noch
weiterkommt, und genau das ist die Frage.
GEMESSEN WIRD JETZT DIE GANZE SEITE und nicht nur die
Zuteilungskarte. Die Zuteilungskarte ist fuer das ANNEHMEN
zustaendig; weitergebracht wird man mit dem Statusknopf
(„starten ▶"), und der steht im Aufgabenbrett darueber. Eine
Pruefung, die nur auf die Karte sieht, haette gemeldet „keine
Knoepfe", waehrend direkt daneben einer steht. */
const knopf = await pAnna.seite.evaluate(() =>
[...document.querySelectorAll(".z-karte .knopf")].map((b) => b.textContent.trim()));
const weiter = await pAnna.seite.evaluate(() =>
[...document.querySelectorAll(".schritt")].map((b) => b.textContent.trim()));
console.log(` Karten-Knoepfe: [${knopf.join(", ")}]`);
console.log(` Schritt-Knoepfe: [${weiter.join(", ")}]`);
/* „Ich fange an" und „Fertig" duerfen NICHT mehr dastehen -- das
ist VanVans Meldung, als Behauptung festgehalten. */
ok(!knopf.includes("Ich fange an") && !knopf.includes("Fertig")
&& !weiter.includes("Ich fange an") && !weiter.includes("Fertig"),
"die zwei Knoepfe, die nur den halben Zustand setzten, sind weg");
ok(weiter.some((t) => /starten|Freigabe|erledigt/.test(t)),
`aber sie kommt weiter — ueber den Statusknopf (${weiter.join(", ") || "KEINER"})`);
/* GEGENPROBE: Es darf KEIN Bewerten-Knopf dastehen. */
const bewerten = await pAnna.seite.evaluate(() =>