Organisation-Konzept: Einstellungen an der Einheit ohne Uebertrumpfen

Festlegung des Nutzers: Einheiten-Einstellungen sind entweder Sammelwerte, die in
die Agenten geschrieben werden (Vorgabe nur fuer neue Mitglieder, Warnung bei
Ausreissern wie Spezialisten), oder Regeln ohne Gegenstueck am Agenten
(Rechte-Obergrenze, beim Schreiben geprueft; Parallelitaet je Einheit).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/Organisation-Konzept.md

@@ -1,6 +1,6 @@
 # Organisation — 50 bis 100 Agenten geordnet zusammenarbeiten lassen
 
-*Stand: 24. September 2026 (ergänzt um 7a, 9a, 10a, Einheiten ohne eigene Konfiguration, Budgetende). Konzept, noch nicht gebaut.*
+*Stand: 24. September 2026 (ergänzt um 7a, 9a, 10a, Einstellungen an der Einheit, Budgetende, Füllarbeit). Konzept, noch nicht gebaut.*
 
 > Herkunft: Richtungsentscheidung des Nutzers am 2026-09-21. Die bisherige Regel im
 > [InstanceSetupGuide](InstanceSetupGuide.md) („mehr als 5 Agenten kritisch
@@ -123,37 +123,46 @@ Instanz „Onlinehandel"
 | **Freigaben** | ein Mensch | die Leitung innerhalb ihrer Grenzen, der Mensch für alles darüber (Geld, Außenwirkung) |
 | **Parallelität** | unbegrenzt | je Einheit und je Instanz eine Zahl gleichzeitiger Läufe, der Rest wartet |
 
-### Eine Einheit hat keine eigene Konfiguration
+### Einstellungen an der Einheit: nie zwei Werte, die sich übertrumpfen
 
-*Festgelegt am 2026-09-24 durch den Nutzer.*
+*Festgelegt am 2026-09-24 durch den Nutzer, in zwei Schritten.*
 
-Was man „für die ganze Einheit" einstellt, wird **nicht an der Einheit gespeichert,
-sondern gesammelt in jeden ihrer Agenten geschrieben**. Wer für das Marketing das
-Tagesbudget je Agent von 5 auf 10 $ hebt, ändert zehn Agentenkonfigurationen auf einmal.
-Eine Einheiten-Einstellung, die im Hintergrund gilt, gibt es nicht.
+Einstellungen lassen sich an der Einheit speichern und bearbeiten. **Aber es gibt nie
+zwei Werte für dieselbe Sache, von denen einer den anderen zur Laufzeit übertrumpft.**
+Daraus folgen genau zwei Arten von Einheiten-Einstellungen:
 
-Der Gewinn: **Was am Agenten steht, gilt.** Man muss nie eine Kette von Einheiten
-hinaufrechnen, um zu wissen, welche Grenze ein Agent wirklich hat. Und ein Umzug ändert
-nichts, was man nicht sieht.
+**1. Sammelwerte, die in die Agenten geschrieben werden.** Alles, was es auch am Agenten
+gibt: Tagesbudget, Modell, Verhalten beim Budgetende (#716). Wer für das Marketing das
+Tagesbudget setzt, schreibt den Wert in jeden Agenten darunter. Die Einheit merkt sich den
+Wert nur als **Vorgabe für Agenten, die neu hinzukommen**, nie als Grenze, die im
+Hintergrund gilt. Danach steht am Agenten, was gilt, und nur dort.
 
-Was die Sammeländerung braucht: eine Vorschau, welche Agenten sich wie ändern, einen
-Audit-Eintrag je Agent und eine Entscheidung, was mit Agenten geschieht, die schon einen
-abweichenden Wert haben. Vorschlag: Die Vorschau zeigt sie gesondert, und der Mensch
-entscheidet, ob sie mit überschrieben werden.
+- **Vorschau** vor dem Schreiben: welche Agenten sich wie ändern, Audit-Eintrag je Agent.
+- **Warnung bei Ausreißern:** Weicht der bisherige Wert eines Agenten massiv von denen
+  seiner Kollegen ab, wird er in der Vorschau hervorgehoben und ist standardmäßig
+  **nicht** angehakt. Gemeint ist der Spezialist, der bewusst viele Tokens verbraucht und
+  sonst mit dem Wert seiner Kollegen kaputtkonfiguriert würde. Der Mensch entscheidet je
+  Ausreißer, ob er mit überschrieben wird.
+- Die Vorschau bietet zwei Rechenwege: **ein Wert je Agent** („jeder bekommt 10 $") oder
+  **ein Gesamtbetrag, verteilt** („das Marketing bekommt 100 $"). Beim Verteilen
+  vorgeschlagen: im Verhältnis der bisherigen Werte, damit ein Spezialist seinen
+  größeren Anteil behält.
 
-**Noch zu klären, weil es drei Stellen dieses Konzepts berührt:**
+**2. Regeln, die es nur an der Einheit gibt.** Sie haben kein Gegenstück am Agenten und
+können deshalb mit nichts konkurrieren:
 
-- **Rechte.** Die Tabelle oben sagt „vererbt von der Einheit; was die Einheit nicht darf,
-  kann ein Mitglied nicht bekommen". Das ist eine Obergrenze an der Einheit, also genau
-  eine gespeicherte Einheiten-Konfiguration. Mit Sammeländerung statt Vererbung entfällt
-  diese Obergrenze: Einem einzelnen Agenten ließe sich später mehr geben als seinen
-  Kollegen. Offen ist, ob das hingenommen wird oder ob die Obergrenze die eine Ausnahme ist.
-- **Parallelität.** Eine Zahl gleichzeitiger Läufe *je Einheit* lässt sich nicht auf
-  Agenten verteilen: Jeder Agent läuft ohnehin nur einmal gleichzeitig. Entweder sie
-  bleibt instanzweit (so ist #682 gebaut), oder sie ist eine zweite Ausnahme.
-- **Grenzen der Leitung** (Abschnitt 12) standen bisher „an der Einheit, nicht an der
-  Person der Leitung". Nach dieser Festlegung stehen sie am Leitungsagenten. Beim
-  Wechsel der Leitung müssen sie dann mit umziehen.
+- **Rechte-Obergrenze.** „Was die Einheit nicht darf, kann ein Mitglied nicht bekommen"
+  bleibt, weil sie eine Sicherheitsgrenze ist. Sie wird **beim Schreiben** geprüft, nicht
+  zur Laufzeit darübergelegt: Eine Rechteänderung am Agenten, die über die Obergrenze
+  hinausginge, wird abgewiesen. Senkt man die Obergrenze, zeigt die Vorschau, welchen
+  Agenten dadurch Rechte entzogen werden, und schreibt es in sie hinein. Damit gilt auch
+  hier: Was am Agenten steht, gilt.
+- **Parallelität je Einheit** (#685). Ein Agent läuft ohnehin nur einmal gleichzeitig,
+  die Zahl gehört also nur der Einheit. Bis #685 gebaut ist, gilt sie instanzweit
+  (`maxParallelTaskRuns`, #682).
+
+**Grenzen der Leitung** (Abschnitt 12) sind ein Sammelwert: Sie stehen am
+Leitungsagenten. Beim Wechsel der Leitung zeigt die Vorschau, was mit umzieht.
 
 ### Beliebig tief, und beweglich
 
@@ -966,6 +975,42 @@ prüft jeder Lauf das Budget einzeln vor dem Start, und bis zu `maxParallelTaskR
 können es gemeinsam überschreiten. Erst mit einer Reservierung vor dem Lauf ist der
 Ausfall vorhersagbar statt eine Frage, welcher Lauf zuerst zugreift.
 
+### Füllarbeit und Großaufgaben
+
+*Ergänzt am 2026-09-24 auf Vorschlag des Nutzers. Item #717.*
+
+Der vorige Abschnitt regelt, was liegen bleibt, wenn das Budget nicht reicht. Die
+Kehrseite: An den meisten Tagen bleibt Budget übrig, und das verfällt.
+
+**Füllarbeit** ist Arbeit, die umfangreich, aber nicht eilig ist. Ob sie heute, morgen
+oder übermorgen läuft, ist gleich. Sie bekommt statt eines Termins eine **Frist
+„spätestens bis"** und läuft, wenn Platz ist. Rechenzentren machen das seit Jahrzehnten
+so und nennen es *Backfilling*. Ob Platz ist, entscheidet der Code:
+
+- Keine regulär fällige Aufgabe des Agenten wartet.
+- Das Restbudget des Tages, abzüglich der Prognose für die noch geplanten Läufe (#608) und
+  eines Sicherheitsaufschlags, reicht für die Schätzung der Füllarbeit.
+- Bevorzugt spät am Tag, weil die Prognose dann am wenigsten Unsicherheit hat.
+
+Rückt die Frist näher und es fand sich nie Platz, wird der Mensch gefragt: Budget
+erhöhen oder Frist verschieben. Eine Füllarbeit überschreitet ihre Frist nie still.
+
+**Großaufgaben** sind Aufgaben, deren Schätzung einen großen Teil des Tagesbudgets
+übersteigt (Vorgabe etwa 50 %). Sie werden nicht einfach angefangen. Der Agent schlägt
+einen von zwei Wegen vor:
+
+1. **Teilen.** Unteraufgaben, jede ein eigener Lauf, verbunden über die Elternaufgabe
+   (Zielkette, Abschnitt 9a). Die Teile können dann Füllarbeit sein.
+2. **Sonderbudget.** Ein Betrag für genau diese Aufgabe samt Unteraufgaben, vom Menschen
+   freigegeben. Es ist ein eigener Topf: Es hebt die Tagesgrenze des Agenten nicht an und
+   ist in der Kostenanalyse gesondert sichtbar. Damit ist es die einzige Ausnahme von
+   „Budgets bleiben am Agenten", gebunden an eine Aufgabe und nie still.
+
+**Ehrlich schätzen.** Kosten lassen sich vorab nicht genau wissen, und Modelle schätzen
+ihren eigenen Aufwand schlecht. Wo es Verlauf gibt, schätzt der Code aus dem Verlauf.
+Sonst schätzt der Agent, und die Zahl ist als Schätzung gekennzeichnet. Nach dem ersten
+Teillauf ersetzt der gemessene Wert die Schätzung.
+
 ### Was die Auswertung dafür braucht
 
 - **Die Einheit als Dimension** in Filtern und Zeitverlauf der Verbrauchsansicht (#660) —
@@ -1295,8 +1340,8 @@ Gegenlesen am 2026-09-22 als zu grob aufgefallen:
   innerhalb ihrer Grenzen liegt", ohne zu sagen, woraus eine Grenze besteht. Vorschlag:
   Betrag je Vorgang, Betrag je Tag, erlaubte Werkzeugklassen, Außenwirkung ja/nein — und
   alles davon an der Einheit, nicht an der Person der Leitung (Stufe 8). *Überholt am
-  2026-09-24: Einheiten speichern keine eigene Konfiguration (Abschnitt 3), die Grenzen
-  stehen damit am Leitungsagenten.*
+  2026-09-24: Grenzen sind ein Sammelwert und stehen am Leitungsagenten (Abschnitt 3,
+  „Einstellungen an der Einheit").*
 - **Wie wird ein Beschluss wirksam?** „Bindend für alles unterhalb" ist ein Wort ohne
   Maschinerie, solange niemand nachsieht. Vorschlag: Das Eskalationswerkzeug sucht von
   sich aus, bevor es einen Vorgang anlegt — genau wie `task_find` vor `task_create`
@@ -1347,6 +1392,7 @@ nur nicht selbst an.
 | #687 | Freigabe durch die Leitung innerhalb von Grenzen |
 | #688 | Organigramm in Oberfläche und WebUI |
 | #716 | Was liegen bleibt, wenn das Budget endet (Ausfall, Nachholen, Reservierung) |
+| #717 | Füllarbeit und Großaufgaben: ungenutztes Budget füllen, teilen oder Sonderbudget |
 | #711 | Lagebild (Teamübersicht): wer arbeitet, wer spricht mit wem, wo klemmt es |
 | #712 | Fremde Laufzeiten: Claude Code, Codex, Befehl, HTTP |
 | #713 | ClawdDotNet als MCP-Server für fremde Laufzeiten |