Vorlagenbrett: Modis bewerben sich, DogFather und die rechte Hand entscheiden

Filipe: "die modis sollen bei all diesen voschlaegen auch nur bewerben
koennen. die aufgaben aus der vorlage, da sollen die modis sich nur
bewerben koennen und nur dogfather und die rechte hand sollen annehmen
oder ablehnen koennen, mit einem text als notiz."

WAS SICH AENDERT
----------------
Auf dem Vorlagenbrett steht fuer einen Modi jetzt "Bewerben" statt
"Uebernehmen". Wer sich beworben hat, sieht das an der Karte -- samt
dem Satz, WER antwortet, und einem Weg zurueck. DogFather und die
rechte Hand sehen die Bewerbung an derselben Karte, mit Namen und dem
Wort dazu, und daneben "Annehmen" und "Ablehnen". Beide fragen nach
einer Notiz.

"ALSO NUR" GILT AUCH AM SERVER, nicht nur im Browser: Die alte Tuer
antwortet einem Modi mit 403 und dem Satz, was stattdessen geht. Ein
ausgeblendeter Knopf ist eine Bitte, abgelehnt wird in der Route.

DIE LINKE HAND STEHT ABSICHTLICH NICHT BEI DEN ENTSCHEIDERN
------------------------------------------------------------
Sie gehoert seit dem 22.09. ueberall dazu ("ich will dass die linke
hand auch ueberall zu sehen ist"). Hier hat Filipe genau zwei genannt.
Das ist keine Vergesslichkeit von mir, sondern seine Aufzaehlung -- und
dieselbe Grenze zieht das Haus schon bei den Aufgaben-Bewerbungen
(entscheidetUeberAufgaben). Sie darf weiter VERTEILEN; das hat er nicht
angefasst.

Sie ist deshalb die schaerfste Probe in der Pruefung: Wer statt "darf
entscheiden" nur "darf verteilen" abfragt, laesst sie mitentscheiden --
und niemandem faellt es auf, weil alles funktioniert.

DIE AUFGABE ENTSTEHT ERST MIT DER ZUSAGE
----------------------------------------
Der naheliegende Weg waere gewesen, beim Bewerben gleich die Aufgabe
anzulegen und die vorhandene Bewerbung aus aufgaben_zuteilung
daranzuhaengen. Dann stuende nach zwoelf Absagen zwoelfmal Arbeit auf
dem Brett, die niemand bestellt hat -- und um das einzufangen, muesste
das Ablehnen Aufgaben LOESCHEN. Loeschen als Nebenwirkung einer Absage
ist genau die Sorte Regel, die irgendwann das Falsche trifft.

Also eine eigene, kleine Tabelle (vorlagen_bewerbungen). Bis jemand ja
sagt, gibt es nur eine Zeile. Die Woerter sind dieselben wie drueben
(zustand, entscheid_text, entschieden_von) -- zwei Namen fuer dieselbe
Sache waeren zwei Sprachen im selben Haus.

Und die Zusage legt die Aufgabe ueber DIESELBE Funktion an wie das
Uebernehmen (katalogAufgabeAnlegen, neu, aus dem Katalog-Zweig
herausgeloest). Damit sieht eine erbetene Aufgabe aus wie eine
verteilte: gleiche Frist, gleiche Kategorie, gleiche Kennung. Ein
zweiter Weg waere ein zweiter Satz Regeln.

KLEINIGKEITEN, DIE SONST WEHTUN
-------------------------------
  * "Alle 12 uebernehmen" gibt es nur fuer die, die verteilen. Ein
    "Alle bewerben" waere der schnellste Weg, zwoelf Bitten auf einmal
    loszuschicken -- und damit zwoelf Entscheidungen fuer jemand anderen.
  * Wer eine Aufgabe schon hat, bekommt keinen Bewerben-Knopf. Der
    Server lehnt das ohnehin ab; ein Knopf, der eine Absage holt, ist
    schlimmer als keiner.
  * Nach einer Absage darf man sich wieder bewerben. Der eindeutige
    Index gilt deshalb nur fuer OFFENE Bewerbungen -- ueber alle
    Zustaende waere eine Absage ein Bann.
  * Gesucht wird ueber den SCHLUESSEL der Vorlage, nicht ueber die
    Nummer in der Liste. Die Nummer verschiebt sich, sobald jemand eine
    Vorlage einfuegt -- genau dieser Fehler ist am 16.09. schon einmal
    passiert.

GEPRUEFT
--------
pruef-modi-katalog: 95 Pruefungen, 0 Fehler (vorher 49).

Die Pruefung ist beim Umbau ROT geworden -- 9 Zeilen, alle dort, wo ein
Modi sich selbst etwas nahm. Richtig so, sie hat die Aenderung bemerkt.
Sie steht jetzt auf dem neuen Weg und misst ihn ganz:

  * der Modi kommt an die alte Tuer nicht mehr heran (403, erst_bewerben)
  * die Bewerbung legt NOCH KEINE Aufgabe an
  * die linke Hand darf verteilen, aber nicht entscheiden (403)
  * der Bewerber selbst erst recht nicht (403)
  * die Zusage erzeugt die Aufgabe -- mit Kategorie, Frist, Besitzer
  * die Notizen stehen in der Datenbank, samt WER entschieden hat
    (direkt gelesen: ein Feld, das der Server annimmt und nirgends
    speichert, saehe von aussen genauso aus)
  * nach einer Absage geht es wieder
  * am Bildschirm: alle Knoepfe heissen "Bewerben", kein einziger
    "Uebernehmen" mehr, die wartende Karte nennt, wer antwortet --
    und DogFather klickt sich durch Annehmen samt Notizfeld, bis die
    Aufgabe auf dem Brett steht

Die Gegenprobe in Abschnitt 7 lief mit dem Zugang des Modis und haette
ab heute nur noch bewiesen, dass die Rechtepruefung greift -- sie
benutzt jetzt DogFather. Genau so verliert eine Pruefung still ihren
Sinn.

pruef-aufgaben-vorlagen: unveraendert gruen.

ZWEI FUNDE NEBENHER, BEIDE AELTER ALS DIESE AENDERUNG -- gemessen, nicht
vermutet (mit gestashten Aenderungen gegengeprueft):
  * pruef-modi-wortleck ist seit dem 22.09. rot: Der Rollenname steht
    in team.css und teamlage.js, also in Dateien, die jeder bekommt.
  * pruef-zuteilung stuerzt seit laengerem ab (#neu-oeffnen ist
    verborgen). Beides kommt als naechstes, getrennt.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/workspace.js

@@ -4542,6 +4542,69 @@ export function db() {
          KEIN ON DELETE CASCADE AUF personen: Wer das Haus verlaesst,
          nimmt die GIFs des Teams nicht mit. "von_id" wird null, die
          Kachel bleibt. */
+      /* BEWERBUNGEN AUF EINE VORLAGE (23.09.2026).
+
+         Filipe: "die modis sollen bei all diesen voschlaegen auch nur
+         bewerben koennen. die aufgaben aus der vorlage, da sollen die
+         modis sich nur bewerben koennen und nur dogfather und die
+         rechte hand sollen annehmen oder ablehnen koennen, mit einem
+         text als notiz."
+
+         WARUM NICHT DIE VORHANDENE BEWERBUNG AUS aufgaben_zuteilung:
+         Die beantwortet "wie steht DIESE Aufgabe bei DIESEM Menschen"
+         -- sie braucht also eine Aufgabe, die es gibt. Hier gibt es
+         noch keine. Es ist eine Bitte um etwas, das erst entstehen
+         soll.
+
+         Der naheliegende Weg waere gewesen, beim Bewerben gleich die
+         Aufgabe anzulegen und die vorhandene Bewerbung daranzuhaengen.
+         Dann steht nach zwoelf Absagen zwoelfmal Arbeit auf dem Brett,
+         die niemand bestellt hat -- und um das zu vermeiden, muesste
+         das Ablehnen Aufgaben wieder LOESCHEN. Loeschen als Nebenwirkung
+         einer Absage ist genau die Sorte Regel, die irgendwann das
+         Falsche trifft.
+
+         Also: Die Aufgabe entsteht erst mit der Zusage. Bis dahin gibt
+         es nur diese Zeile.
+
+         DIE WORTE SIND DIESELBEN WIE DRUEBEN (zustand, entscheid_text,
+         entschieden_von, entschieden_am). Zwei Namen fuer dieselbe
+         Sache waeren zwei Sprachen im selben Haus.
+
+         "aufgabe_id" steht nach der Zusage darin -- damit laesst sich
+         von der Bewerbung aus zeigen, was aus ihr geworden ist. Kein
+         Fremdschluessel: Wird die Aufgabe spaeter geloescht, bleibt die
+         Bewerbung als Vorgang stehen; sie hat stattgefunden.
+
+         ON DELETE CASCADE auf personen: Wer das Haus verlaesst,
+         hinterlaesst keine Bewerbung, auf die jemand noch antworten
+         soll. */
+      CREATE TABLE IF NOT EXISTS vorlagen_bewerbungen (
+        id             INTEGER PRIMARY KEY AUTOINCREMENT,
+        vorlage        TEXT NOT NULL,
+        kategorie      TEXT,
+        person_id      INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
+        text           TEXT,
+        zustand        TEXT NOT NULL DEFAULT 'beworben',
+        entscheid_text TEXT,
+        entschieden_von INTEGER REFERENCES personen(id) ON DELETE SET NULL,
+        entschieden_am TEXT,
+        aufgabe_id     INTEGER,
+        erstellt       TEXT NOT NULL
+      );
+      /* EINMAL BEWERBEN, NICHT DREIMAL -- und zwar von der Datenbank
+         durchgesetzt, nicht von einer Abfrage davor, die man vergessen
+         kann.
+
+         NUR AUF OFFENE: Wer abgelehnt wurde, darf sich spaeter wieder
+         bewerben (Lage aendert sich, Woche aendert sich). Ein Index
+         ueber ALLE Zustaende haette genau das verboten. */
+      CREATE UNIQUE INDEX IF NOT EXISTS idx_vorlagen_bewerbung_offen
+        ON vorlagen_bewerbungen (vorlage, person_id) WHERE zustand = 'beworben';
+      /* Die Frage im Betrieb lautet "was wartet gerade auf Antwort?" */
+      CREATE INDEX IF NOT EXISTS idx_vorlagen_bewerbung_zustand
+        ON vorlagen_bewerbungen (zustand, id);
+
       CREATE TABLE IF NOT EXISTS chat_gifs (
         id       INTEGER PRIMARY KEY AUTOINCREMENT,
         datei    TEXT NOT NULL,