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). 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,6 +123,47 @@ 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 |
 
+### Einstellungen an der Einheit: nie zwei Werte, die sich übertrumpfen
+
+*Festgelegt am 2026-09-24 durch den Nutzer, in zwei Schritten.*
+
+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:
+
+**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.
+
+- **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.
+
+**2. Regeln, die es nur an der Einheit gibt.** Sie haben kein Gegenstück am Agenten und
+können deshalb mit nichts konkurrieren:
+
+- **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
 
 Eine Einheit enthält Einheiten, und die wieder Einheiten — **ohne feste Grenze**.
@@ -888,6 +929,88 @@ muss. Also:
 Erkennen ist auch hier Code, nicht Modell: Ein Mittelwert und ein Schwellwert sind eine
 Abfrage. Ob die Abweichung ein Problem ist, deutet die Aufsicht (#680).
 
+### Was liegen bleibt, wenn das Budget endet
+
+*Ergänzt am 2026-09-24 auf Hinweis des Nutzers. Item #716.*
+
+Um 22:30 ist das Tagesbudget aufgebraucht, und für den Rest des Tages stehen noch 100
+Läufe an. Lässt man sie verfallen, fehlt Arbeit. Holt man sie nach, fressen sie das
+Budget des nächsten Tages.
+
+**Heute gibt es dafür schon ein Verhalten. Nur hat es niemand entschieden.** Der Ausfall
+wird vermerkt (seit #608 als RunReceipt mit `BudgetExceeded`), aber nicht an der Aufgabe
+und nicht zusammengefasst. Einmalige Aufgaben werden alle 30 Minuten erneut versucht und
+laufen nach Mitternacht still zu Lasten des neuen Tages. Wiederkehrende verfallen still,
+weil ihr Termin schon beim Beanspruchen verbraucht ist. Beides kann richtig sein, aber
+nicht, ohne dass es jemand festlegt. Die Tagesgrenze ist die lokale Mitternacht.
+
+Der Vorschlag ist eine Einstellung je Agent, was mit einem Lauf geschieht, der am Budget
+scheitert:
+
+| Regel | Was geschieht | Voreinstellung für |
+|---|---|---|
+| `expire` | verfällt, wird an der Aufgabe vermerkt | wiederkehrende Aufgaben: Der nächste Termin kommt ohnehin, ein verpasster Stundenbericht ist vom nächsten überholt |
+| `catch_up_once` | alle verfallenen Termine werden zu **einem** Nachholauf zusammengefasst | — (sinnvoll für den Tagesbericht, dessen nächster Termin erst in 24 Stunden käme) |
+| `carry_over` | wird mitgenommen | einmalige Aufgaben: echte Arbeit, die nicht verschwinden darf |
+
+Dazu gilt: **Der neue Tag hat Vorfahrt.** Nachholläufe kommen nach den regulär fälligen,
+unterhalb jeder Priorität, und dürfen höchstens einen Anteil des neuen Tagesbudgets
+verbrauchen (Vorgabe etwa 25 %). Ohne diese Regel schiebt ein einziger überzogener Tag
+seinen Ausfall Tag für Tag vor sich her, statt ihn aufzulösen. Eine einmalige Aufgabe, die
+nach einigen Tagen immer noch nicht drankam, geht an den Menschen: Was nie läuft, darf
+nicht unbemerkt liegen bleiben.
+
+**Vermerkt wird zweimal:** an der Aufgabe („ausgefallen: Budget erschöpft, 22:30" bzw.
+„nachgeholt am …") und in einer Tageszusammenfassung („Budget Marketing um 22:30
+erschöpft, 100 Läufe ausgefallen, 12 zum Nachholen vorgemerkt"). Die Zusammenfassung
+geht in die Abweichungsmeldung oben und ins Lagebild (Abschnitt 10a).
+
+**Besser als jede Nachholregel ist Vorbeugen.** Die Kostenprognose aus #608 weiß schon
+heute, ob das Budget für die geplanten Aufgaben reicht. Sie sollte vormittags melden,
+dass bei diesem Verbrauch um 22:30 Schluss ist. Dann kann der Mensch rechtzeitig
+nachlegen oder entscheiden, was entfällt.
+
+Zur selben Baustelle gehört die **Budgetreservierung**, der offene Rest aus #682: Noch
+prüft jeder Lauf das Budget einzeln vor dem Start, und bis zu `maxParallelTaskRuns` Läufe
+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) —
@@ -1216,7 +1339,9 @@ Gegenlesen am 2026-09-22 als zu grob aufgefallen:
 - **Was ist eine „Grenze" der Leitung?** Das Konzept sagt „die Leitung gibt frei, was
   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).
+  alles davon an der Einheit, nicht an der Person der Leitung (Stufe 8). *Überholt am
+  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`
@@ -1266,6 +1391,8 @@ nur nicht selbst an.
 | #654, #196, #657 | Sandbox, Shell, Skriptprüfung — der eigentliche Werkzeugkasten |
 | #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 |