Bisher hatten Scouts mit der Creator-Betreuung nichts zu tun -- keine
Profile, keine Betreuungsbereiche, keine Reports. Das aendert sich, mit
zwei bewusst gesetzten Grenzen.
GRENZE 1: nur zugeteilte Creator, keine Rollenregel.
Neue Tabelle betreuung (creator_id PRIMARY KEY -> betreuer_id). Ein
Creator hat genau EINE zustaendige Person, damit nie unklar ist, wer
gefragt ist. Das Management sieht ohnehin alle und braucht keinen
Eintrag. Wer nichts zugeteilt bekommt, sieht weiterhin nichts -- kein
Recht entsteht automatisch aus der Rolle.
Zugeteilt wird in "Personen & Zugaenge", direkt in der Personenzeile:
Betreuung ist eine Eigenschaft der Person, kein eigener Vorgang. Nur das
Management darf zuteilen -- koennte ein Scout sich selbst Creator geben,
haette er die Rechtevergabe in der Hand, die ihn begrenzen soll.
Zustaendig koennen nur aktive Scouts sein, kein Admin (der sieht alles)
und kein anderer Creator.
Bei der Uebergabe aus der Pipeline passiert die Zuteilung von selbst:
Wer jemanden gefunden hat, betreut ihn weiter. Genau darum geht es bei
"Creator-Onboarding starten". Umhaengen kann das Management jederzeit.
GRENZE 2: betreuen, nicht verwalten.
Profile, die fuenf Bereiche und Reports wie ein Manager. ABER:
- keine Zugangscodes, kein Sperren von Personen (personen.html bleibt
admin-only, unveraendert)
- keine management-internen Felder. Der Scout bekommt admin_notiz,
plan_start und naechster_review NICHT -- die Felder fehlen in der
Antwort komplett, nicht nur in der Anzeige. Eine Notiz UEBER die
Betreuung gehoert nicht in die Hand dessen, der betreut. Geprueft: Ein
Scout, der admin_notiz mitschickt, aendert sie nicht.
Die Regel steht an EINER Stelle (betreuteIds / betreutWo / darfCreator
in workspace.js) und wird von sechs Modulen benutzt. Eine Rechteregel,
die an sechs Stellen steht, ist eine Rechteregel, die irgendwann an
fuenf Stellen stimmt.
Genau das ist beim Bauen auch passiert: workspace-calls.js hatte eine
wortgleiche Kopie der Kalender-Sichtbarkeit. Erweitert wurde nur der
Kalender -- Scouts sahen die Termine ihrer Creator, dieselben Termine
als Call aber nicht. Die Kopie ist jetzt weg, calls.js importiert die
Regel aus workspace-kalender.js.
Zwei Fehler, die die Aenderung selbst erzeugt haette, vorher gefunden:
- Report-Entscheidung: ein Scout haette eine Aufgabe angelegt, deren
"Creator" er selbst ist -- die waere in jeder Auswertung falsch
mitgelaufen. Zeigt jetzt auf einen seiner Creator.
- Bereichseintrag: derselbe Fehler. Ein Scout hat gar keinen eigenen
Betreuungsbereich. Ein Eintrag ohne oder mit fremder Zuordnung landet
beim ersten zugeteilten Creator, nie bei einem fremden. Geprueft:
Mikas Bereich bleibt bei jedem Versuch unberuehrt.
/workspace/report.html. Fuehrt bewusst KEINE eigenen Eintraege, sondern
fasst zusammen, was in Aufgaben, Bereichen, Terminen und Dateien schon
steht: "Fortschritt wird nicht gefuehlt, sondern nachvollziehbar
gemacht".
Die vier Abschnitte sind woertlich die Fragen aus dem Deck, Seite 16:
Was wurde erledigt? Was blockiert? Was hat funktioniert? Was kommt als
Naechstes?
Zwei Punkte daraus sind ernst genommen:
1. "Vorher / nachher" (Historie). Jede Zahl wird mit demselben,
unmittelbar davorliegenden Zeitraum verglichen. Eine Zahl allein sagt
wenig -- 3 erledigte Aufgaben sind gut oder schlecht, je nachdem ob es
vorher 1 oder 9 waren. Bei Zahlen, wo mehr SCHLECHTER ist (offene
Probleme), ist die Trendfarbe umgedreht.
2. "Jeder Review endet mit einer Entscheidung, nicht nur mit einer
Zusammenfassung." Der Report legt deshalb direkt eine Aufgabe an --
ohne Seitenwechsel, mit hoher Prioritaet und optionaler Frist.
Geprueft: Eintrag im Report -> Aufgabe erscheint im Brett.
"Was blockiert?" zeigt zusaetzlich die drei am laengsten offenen
Aufgaben mit Namen, nicht nur eine Zahl.
Sichtbarkeit:
- Scout: 404, sowohl Schnittstelle als auch Seite (leitet weg)
- Creator: sieht nur sich. Geprueft -- Luna fordert ?creator=3 (Mika) an
und bekommt einen Report ueber SICH, der Parameter wird fuer
Nicht-Management ignoriert
- Der Review-Termin aus dem Profil ist Steuerungswissen und wird einem
Creator auch hier nicht mitgeschickt, genau wie im Profil selbst
Damit ist Phase 2 aus dem Konzept vollstaendig.
DogFatherGit