Merge docs/budgetende-einheiten-konfig

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, Einheiten ohne eigene Konfiguration, Budgetende). 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,38 @@ 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
+
+*Festgelegt am 2026-09-24 durch den Nutzer.*
+
+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.
+
+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.
+
+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.
+
+**Noch zu klären, weil es drei Stellen dieses Konzepts berührt:**
+
+- **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.
+
 ### Beliebig tief, und beweglich
 
 Eine Einheit enthält Einheiten, und die wieder Einheiten — **ohne feste Grenze**.
@@ -888,6 +920,52 @@ 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.
+
 ### Was die Auswertung dafür braucht
 
 - **Die Einheit als Dimension** in Filtern und Zeitverlauf der Verbrauchsansicht (#660) —
@@ -1216,7 +1294,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: Einheiten speichern keine eigene Konfiguration (Abschnitt 3), die Grenzen
+  stehen damit am Leitungsagenten.*
 - **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 +1346,7 @@ 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) |
 | #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 |