Organisation: viele gemeinsame Bereiche, Doctrine, Kostenanalyse (#698-#700)

Der Ordner SharedWorkspace wird zu SharedWorkspaces: mehrere benannte
Bereiche mit Eigentuemer und Mitgliederliste, je Einheit einer als
Normalfall, abteilungsuebergreifende ausdruecklich. Das Recht steht am
Bereich, nicht am Agenten - Marketing sieht die Ablage der Buchhaltung
nicht, und erfaehrt auch nicht, dass es sie gibt.

Zwei offene Fragen entschieden:
- Budgets bleiben am Agenten. Die Einheit rechnet auf und meldet
  Abweichungen vom eigenen Verlauf. Damit entfaellt die Zuteilungsrechnerei,
  und ein Umzug aendert keine einzige Grenze.
- Eine Eskalation, die nicht geloest werden kann, darf es nicht geben. Nach
  einer Frist wird der Mensch gerufen, der entscheidet oder Stellungnahmen
  anfordert. "Bleibt sichtbar liegen" war zu schwach.

Neu: Die Doctrine.md gibt einer Leitung ein Steuermittel neben Identity und
Soul - eine Ebene tief, kurz, gedeckelt, und freigabepflichtig, wenn der
schreibende Lauf fremde Inhalte gelesen hat.

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

docs/Organisation-Konzept.md

@@ -116,10 +116,10 @@ Instanz „Onlinehandel"
 | Was | Heute | Mit Einheiten |
 |---|---|---|
 | **Adressbuch** | alle | die eigene Einheit, die eigene Leitung. Eine Leitung sieht zusätzlich die Leitungen der Geschwistereinheiten |
-| **Arbeitsbereich** | `personal`, `shared` | `personal`, `einheit`, `shared`. Die Abteilungsablage ist der Normalfall, `shared` die Ausnahme |
+| **Arbeitsbereich** | `personal`, `shared` | `personal` plus **mehrere benannte gemeinsame Bereiche** mit Mitgliederliste — siehe unten |
 | **Rechte** | je Agent | vererbt von der Einheit, je Agent verschärfbar. Was die Einheit nicht darf, kann ein Mitglied nicht bekommen |
 | **Taskboard** | ein Brett | ein Brett je Einheit; `task_list` zeigt die eigene Einheit, die Leitung sieht die Untereinheiten |
-| **Budget** | Agent, Instanz | Agent, Einheit, Instanz — jede Ebene deckelt die darunter |
+| **Budget** | Agent, Instanz | Grenzen bleiben am Agenten; die Einheit summiert auf und meldet Abweichungen — siehe Abschnitt 8a |
 | **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 |
 
@@ -165,6 +165,44 @@ Drei Festlegungen dazu:
    Strukturänderung ist eine Rechteänderung, und die gehört nachvollziehbar — Linie von
    #205 und #641.
 
+### Arbeitsbereiche: aus einem gemeinsamen werden viele
+
+Heute gibt es genau zwei — `personal` und `shared` —, und `shared` ist ein Dorfplatz, auf
+dem jeder alles sieht. Bei fünfzig Agenten ist das untragbar: Ein Marketing-Agent hat auf
+der Ablage der Buchhaltung nichts zu suchen.
+
+**Der Ordner `SharedWorkspace` wird deshalb zu `SharedWorkspaces` — einem Behälter für
+viele.** Jeder darin ist ein eigener Bereich mit Namen, Eigentümer und Mitgliederliste:
+
+```
+SharedWorkspaces/
+├── einkauf/                 Mitglieder: Einkauf (alle Untereinheiten)
+├── einkauf-lieferanten/     Mitglieder: Team Lieferanten
+├── buchhaltung/             Mitglieder: Buchhaltung — Marketing sieht das nie
+├── leitungsrunde/           Mitglieder: die Abteilungsleitungen
+├── artikelstamm/            abteilungsübergreifend: Einkauf schreibt, Marketing liest
+└── haus/                    alle — für das wenige, das wirklich alle angeht
+```
+
+Vier Festlegungen:
+
+1. **Jede Einheit bekommt beim Anlegen ihren eigenen Bereich**, Mitglieder sind ihre
+   Agenten und ihre Untereinheiten. Das ist der Normalfall, und er kostet keine
+   Entscheidung.
+2. **Abteilungsübergreifende Bereiche sind gewollt und ausdrücklich.** Der Artikelstamm
+   gehört dem Einkauf und wird vom Marketing gelesen — das ist eine Festlegung mit
+   benanntem Eigentümer, kein Nebenprodukt. Genau das, was Abschnitt 9 verlangt.
+3. **Das Recht steht am Bereich, nicht am Agenten.** Heute trägt jeder Agent ein
+   `sharedAccessLevel` für den *einen* gemeinsamen Bereich. Künftig hat jeder Bereich
+   seine Mitglieder mit Stufe (lesen / schreiben / verwalten). Wer nicht auf der Liste
+   steht, sieht den Bereich nicht — auch nicht, dass es ihn gibt.
+4. **Ein Umzug ändert die Mitgliedschaft, nicht den Inhalt.** Zieht ein Agent um, verliert
+   er den alten Bereich und bekommt den neuen. Was er dort abgelegt hat, bleibt liegen —
+   es gehört der Einheit.
+
+Für bestehende Instanzen bleibt `workspace: "shared"` gültig und zeigt auf den einen
+Bereich, den es dort gibt. Ohne das bräche jede Aufgabe, die heute läuft.
+
 ### Die eine Regel, die alles zusammenhält
 
 **Ein Agent kennt nur seine Einheit und seine Leitung.** Alles andere geht über die
@@ -615,6 +653,44 @@ Modell stilllegt oder umkonfiguriert, verändert die Organisation ohne menschlic
 Beteiligung. Die Leitung *schlägt vor* und begründet; ausgeführt wird nach Freigabe —
 Linie von #205, #641, #687.
 
+### Die Doctrine: wie eine Leitung steuert, ohne jeden Auftrag anzufassen
+
+Ein Agent wird heute von zwei Texten geprägt: `Identity.md` sagt, **wer** er ist,
+`Soul.md`, **wie** er arbeitet. Beides ändert nur ein Mensch (#205).
+
+Einer Leitung fehlt damit ein Mittel. Sie kann Aufträge verteilen und Ergebnisse prüfen —
+aber nicht sagen: „In dieser Abteilung gilt ab sofort, dass jeder Lieferantenkontakt in
+der Datenbank landet, bevor er weitergegeben wird." Dafür müsste sie jeden Aufgabentext
+einzeln ändern.
+
+**Die Leitung legt deshalb eine `Doctrine.md` in den Ordner ihrer unterstellten Agenten.**
+Ein dritter Text neben Identity und Soul: nicht wer und nicht wie, sondern **was in dieser
+Einheit gerade gilt**.
+
+Vier Festlegungen:
+
+1. **Nur eine Ebene tief.** Die Doctrine einer Abteilungsleitung erreicht die Agenten
+   *ihrer* Einheit — sie stößt nicht automatisch in die Untereinheiten durch. Ein Team
+   unter ihr hat seine eigene Leitung, und die schreibt ihre eigene. Wäre es anders,
+   summierten sich bei fünf Ebenen fünf Doktrinen in jedem Prompt, und niemand wüsste
+   mehr, welche Regel woher kommt.
+2. **Selten und sichtbar.** Eine Doctrine, die wöchentlich wechselt, ist keine Doktrin,
+   sondern Mikromanagement mit Tokenkosten. Erzwingen lässt sich das nicht — beobachten
+   schon: Jede Änderung steht im Audit mit Vergleich zur Vorfassung, und häufige
+   Änderungen sind ein Befund für die Aufsicht (#680).
+3. **Kurz und gedeckelt.** Sie geht in *jeden* Lauf *jedes* unterstellten Agenten. Fünf
+   Agenten mal vierzig Läufe am Tag mal tausend Token sind 200.000 Token täglich für
+   einen Text, den niemand mehr liest. Eine Höchstlänge gehört dazu.
+4. **Eine belastete Leitung schreibt nicht frei.** Hat der Lauf, in dem die Leitung die
+   Doctrine ändert, fremde Inhalte gelesen — eine Mail, eine Webseite, einen
+   Lieferantenbericht —, dann ist die Änderung freigabepflichtig (#651, #659). Sonst wäre
+   die Doctrine der bequemste Weg, einer ganzen Abteilung von außen etwas unterzuschieben:
+   ein Text, der ungefragt in jedem Prompt steht.
+
+Ansonsten darf die Leitung sie ändern, ohne zu fragen. Das ist der Unterschied zu
+Identity und Soul, und er ist gewollt: Eine Leitung, die für jede Anweisung an ihre
+eigene Abteilung einen Menschen braucht, ist keine Leitung.
+
 ### A/B: welches Modell macht es besser oder billiger?
 
 Die Eignungsprobe (#681) beantwortet „kann dieses Modell dieses Werkzeug bedienen?" —
@@ -638,6 +714,69 @@ Drei Dinge machen den Unterschied zwischen einer Messung und einem Gefühl:
 Das Ergebnis ist wieder eine Empfehlung, keine Umstellung: Der Personalmanager legt sie
 vor, entschieden wird mit Freigabe.
 
+## 8a — Kosten und Prompts: das wichtigste Instrument
+
+Je größer das Haus, desto weniger sieht man von innen. **Was eine Organisation aus fünfzig
+oder hundert Agenten noch steuerbar macht, ist die genaue Erfassung dessen, was sie
+kostet und was sie einander sagt.** Ein solches Haus wird früher oder später einige
+hundert Dollar im Monat verbrauchen — und die Frage ist nie „können wir uns das
+leisten?", sondern „wo davon ist Verschwendung?".
+
+Die Datenbasis steht bereits: `RunReceipts` (Schritte, Tokens, Kosten je Lauf),
+`RunUsage`, `AuditLog` und die Prompt-History aus #660. Was fehlt, ist die Ebene der
+Einheit darin — heute lässt sich nur je Agent auswerten.
+
+### Grenzen bleiben am Agenten, die Einheit rechnet auf
+
+Festgelegt am 2026-09-22: **Token- und Kostengrenzen bleiben da, wo sie heute sind — am
+einzelnen Agenten.** Auf Einheitsebene wird gerechnet, nicht gedeckelt:
+
+- **Tatsächliche Kosten** je Einheit, aufsummiert über ihre Agenten und Untereinheiten
+- **Theoretisches Maximum** je Einheit, als Summe der Agentengrenzen darunter
+- beides je Tag, Woche, Monat — und im Vergleich zum Vormonat
+
+Das ist die sparsamste Lösung, und sie hat einen Vorteil, der erst beim Umziehen auffällt:
+**Ein Umzug ändert keine einzige Grenze.** Wäre das Budget der Einheit eine Zuteilung,
+müsste bei jeder Umorganisation neu gerechnet werden — bei einer Instanz, die mit ihrem
+Projekt wächst, also dauernd.
+
+### Die Meldung ist wichtiger als die Grenze
+
+Eine Grenze sagt nur, wann Schluss ist. Was man wirklich wissen will, ist, wann sich etwas
+**ändert**:
+
+> Die Agenten der Marketingabteilung dürften zusammen 100 $ am Tag ausgeben. Seit Wochen
+> brauchen sie 30 $. Heute sind es 80 $.
+
+Da ist nichts überschritten — und trotzdem ist genau das der Moment, in dem man hinsehen
+muss. Also:
+
+- **Abweichung vom eigenen Verlauf.** Ein gleitender Mittelwert je Einheit über die
+  letzten Wochen; wird er deutlich überschritten, geht eine Meldung raus. Das findet
+  Schleifen, entgleiste Aufgaben und teure Modellwechsel, bevor sie einen Monat lang
+  laufen.
+- **Annäherung an die Grenze.** Wenn die Summe der Agentengrenzen einer Einheit zu einem
+  hohen Anteil ausgeschöpft wird, ebenfalls eine Meldung — bevor Agenten reihum in ihr
+  Limit laufen.
+- **Gesamtbetrag erreicht.** Schwellen je Monat, die nichts abschalten, sondern melden.
+
+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 die Auswertung dafür braucht
+
+- **Die Einheit als Dimension** in Filtern und Zeitverlauf der Verbrauchsansicht (#660) —
+  „was kostet mich das Marketing?" muss eine Frage sein, keine Rechenaufgabe.
+- **Verdichtete Werte.** Tagessummen je Agent und Einheit, damit eine Sechsmonatsansicht
+  nicht Millionen Laufzeilen liest (#700).
+- **Aufbewahrung auch für Audit und Receipts (#700).** Für Transkripte gibt es eine Frist
+  und einen Kehrbesen (#660), für `RunUsage` eine Löschung — für `AuditLog` und
+  `RunReceipts` nichts. Gemessen auf der Testinstanz: 636 Läufe erzeugen 4.155
+  Audit-Zeilen. Hundert Agenten kämen auf etwa 7.400 Zeilen am Tag, also einige Millionen
+  im Jahr — in genau der Tabelle, die jede Auswertung liest.
+
+---
+
 ## 9 — Was eine Organisation braucht und ein Agentenhaufen nicht
 
 Der Punkt, der beim Bauen am leichtesten übersehen wird: **Eine Organisation lebt von
@@ -694,7 +833,8 @@ für sich schon nützt und keine die nächste blockiert.
 | **6** | Besprechung als Mittel, mit Protokoll | Leitungen können sich abstimmen, ohne *n²* Nachrichten |
 | **7** | Entscheidungsinstanz an der Spitze (#690) | Der Betrieb läuft weiter, wenn der Mensch schläft |
 | **8** | Freigabe durch die Leitung innerhalb von Grenzen | Der Mensch hört auf, Flaschenhals zu sein |
-| **9** | Kontrollpflicht der Leitung, abgestufte personelle Mittel (#693) | Fehler findet die Leitung, nicht erst der Mensch |
+| **9** | Kontrollpflicht der Leitung, abgestufte personelle Mittel (#693); Doctrine (#698) | Fehler findet die Leitung, nicht erst der Mensch — und sie kann steuern |
+| **9a** | Kosten je Einheit, Abweichungsmeldung (#699), Aufbewahrung (#700) | Ineffizienz wird sichtbar, bevor sie einen Monat lang läuft |
 | **10** | Oberfläche: Organigramm statt Agentenliste, Lage je Abteilung | Bei fünfzig Agenten ist eine flache Liste keine Übersicht |
 | **11** | Organisationsvorlagen (#691) | Ein Haus lässt sich weitergeben statt nachbauen |
 
@@ -740,13 +880,12 @@ wächst, wird der Umzug teurer.
 Vier weitere, die vor dem Bau der jeweiligen Stufe entschieden gehören — beim
 Gegenlesen am 2026-09-22 als zu grob aufgefallen:
 
-- **Ist ein Einheitsbudget ein Deckel oder eine Zuteilung?** Hat Marketing 20 $ und jedes
+- ~~**Ist ein Einheitsbudget ein Deckel oder eine Zuteilung?**~~ **Entschieden am
-  seiner drei Teams 10 $, sind das 30 $ — bei Deckel-Bedeutung gilt trotzdem die 20, und
+  2026-09-22: weder noch.** Harte Grenzen bleiben am Agenten. Die Einheit rechnet auf und
-  wer zuerst kommt, mahlt zuerst. Bei Zuteilung müsste die Summe aufgehen. Vorschlag:
+  zeigt an — siehe Abschnitt 8a. Damit entfällt die ganze Zuteilungsrechnerei, und ein
-  **Deckel**, weil Zuteilung bei jeder Umorganisation neu gerechnet werden muss — plus
+  Umzug ändert keine einzige Grenze. Die Parallelität bleibt davon unberührt: Sie ist
-  eine Mindestzusage je Unterteilung, damit ein gefräßiges Team die Geschwister nicht
+  keine Kostenfrage, sondern eine Frage der Ratengrenzen, und wird je Instanz gedeckelt
-  aushungert. Dieselbe Frage stellt sich bei der Parallelität, und sie gehört gleich
+  (#682).
-  beantwortet (Stufe 3).
 - **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
@@ -755,10 +894,12 @@ Gegenlesen am 2026-09-22 als zu grob aufgefallen:
   Maschinerie, solange niemand nachsieht. Vorschlag: Das Eskalationswerkzeug sucht von
   sich aus, bevor es einen Vorgang anlegt — genau wie `task_find` vor `task_create`
   (#674). Ein Beschluss, den man aktiv lesen müsste, wird nicht gelesen (Stufe 5).
-- **Was passiert, wenn die Eskalationsgrenze erreicht ist?** Vorgeschlagen war „zählen
+- ~~**Was passiert, wenn die Eskalationsgrenze erreicht ist?**~~ **Entschieden am
-  und deckeln", ohne zu sagen, was der Deckel tut. Vorschlag: dieselbe Behandlung wie bei
+  2026-09-22, und schärfer als vorgeschlagen: Eine Eskalation, die nicht gelöst werden
-  erschöpftem Budget (#643) — der Vorgang bleibt offen und sichtbar liegen, statt
+  kann, darf es nicht geben.** Finden die Agenten binnen einer einstellbaren Frist keine
-  abgewiesen zu werden. Eine verworfene Eskalation ist ein verlorenes Problem (Stufe 5).
+  Lösung, wird der Mensch gerufen. Er entscheidet — oder fordert an, was ihm fehlt, etwa
+  eine Stellungnahme jeder Streitpartei. „Bleibt sichtbar liegen" war zu schwach: Ein
+  Vorgang, den niemand anfasst, ist auch dann verloren, wenn er sichtbar ist (Stufe 5).
 
 Und eine Kleinigkeit mit Folgen: **Das Wort „Struktur" meint in Abschnitt 6 die
 Organisation** (Einheiten, Rechte, Grenzen) — nicht ein Datenbankschema. Eine
@@ -786,6 +927,9 @@ nur nicht selbst an.
 | #695 | Skripte: Schreiben und Benutzen sind zwei Rechte, mit Lieferkette |
 | #696 | Fehlerablage je Skript — der Läufer schreibt, der Eigentümer liest |
 | #697 | Stille Post vermeiden: Weitergaben hängen an und tragen den Verweis |
+| #698 | Doctrine.md — die Leitung steuert ihre Einheit, eine Ebene tief |
+| #699 | Kosten je Einheit aufrechnen und Abweichungen melden |
+| #700 | Aufbewahrung für Audit und Receipts, verdichtete Tageswerte |
 | #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 |