Organisation: Baukasten-Trennung, Eskalation und Entscheidungsinstanz (#689-#692)

Das Produkt bringt Baum, Mittel, Werkzeugkasten und Grenzen mit; welche
Abteilungen es gibt, ist eine Zeile in einer Datei. Im Code steht nirgends
das Wort "Einkauf". Daraus folgt die Organisationsvorlage (#691) - ein
ganzes Haus als weitergebbare Datei.

Der Eskalationsfall aus dem Vorschlag zerfaellt in drei Mittel (#689):
Eskalation geht nach oben, ein Konflikt wird bei der niedrigsten gemeinsam
uebergeordneten Stelle entschieden - eine Regel, die fuer jedes Organigramm
gilt, ohne dass jemand Wege konfiguriert -, und ein Beschluss ist dauerhaft,
sonst wird dieselbe Frage naechste Woche erneut durch vier Ebenen getragen.

Die Spitze ist eine Rolle, kein CEO-Agent (#690): Mensch, Agent oder Mensch
mit Frist. Wer entscheidet, fuehrt nicht aus und aendert die Struktur nicht.

Vorbedingung des ganzen Falls: Das Datenbank-Werkzeug kann heute nicht nach
dem Schema fragen (#676). "Ich finde kein Feld dafuer" ist damit eine
Vermutung, und eine Organisation soll keine Einbildungen eskalieren.

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

docs/Organisation-Konzept.md

@@ -7,10 +7,13 @@
 > hinterfragen") ist damit zurückgezogen.
 >
 > **Das Ziel:** ClawdDotNet ist der Harness — das Büro, der Konferenzraum, die Groupware
-> der Agenten. Eine Instanz betreibt einen Onlinehandel mit Einkauf, Buchhaltung,
+> der Agenten. 50 bis 100 Agenten arbeiten parallel an einem großen Vorhaben, nie alle
-> Marketing und Logistik; jede Abteilung hat mehrere Agenten, dazu Leitungen und
+> gleichzeitig, aber alle an derselben Sache.
-> beliebig viele weitere Ebenen. 50 bis 100 Agenten arbeiten parallel an einem großen
+>
-> Vorhaben, nie alle gleichzeitig, aber alle an derselben Sache.
+> **Universell, nicht für einen Fall.** Ein Baukasten für eine KI-Firma. Der Onlinehandel
+> in diesem Dokument ist ein Beispiel zur Verdeutlichung, kein Bauplan — andere Gebilde
+> haben andere Organigramme, und auch die sollen sich abbilden lassen. Was das Produkt
+> mitbringt, sind Struktur und Mittel. Was eine bestimmte Firma ausmacht, sind Daten.
 
 ---
 
@@ -33,6 +36,29 @@ Leitung der Gegenseite. Das ist keine Bürokratie, sondern der Grund, warum echt
 Organisationen mit tausend Menschen funktionieren und eine Gruppenchat-Gruppe mit
 fünfzig nicht.
 
+### Was das Produkt mitbringt und was die Firma ausmacht
+
+Die Trennung entscheidet darüber, ob daraus ein Baukasten wird oder eine
+Handelssoftware. Sie ist scharf zu halten:
+
+| Im Produkt | In der Instanz |
+|---|---|
+| Der **Baum**: Einheiten, Leitung, Mitgliedschaft, Vererbung | *Welche* Abteilungen es gibt und wie sie heißen |
+| Die **Mittel**: Delegation, Eskalation, Konflikt, Besprechung, Beschluss | *Wann* eskaliert wird und wer entscheidet |
+| Der **Werkzeugkasten** (Abschnitt 7) | Welche Werkzeuge welche Einheit bekommt |
+| Die **Grenzen**: Rechte, Budgets, Parallelität, Freigaben | Wie hoch sie stehen |
+
+Im Produkt steht nirgends das Wort „Einkauf". Eine Abteilung ist eine Einheit mit einem
+Namen, und ob sie Einkauf, Redaktion, Labor oder Kanzlei heißt, ist eine Zeile in einer
+Datei.
+
+**Daraus folgt die Organisationsvorlage (#691):** Eine Struktur — Einheiten, Rollen,
+deren Aufgaben, Werkzeuge, Rechte und Budgets — ist eine beschreibbare, importierbare,
+weitergebbare Datei. Dieselbe Idee wie bei den Basisagenten
+([Basisagenten-Konzept](Basisagenten-Konzept.md)), eine Ebene höher: dort eine Rolle,
+hier ein ganzes Haus. Wer eine Vorlage „Onlinehandel" oder „Redaktion" schreibt, hat
+damit keinen Code geschrieben.
+
 ---
 
 ## 2 — Was heute bei 50 Agenten bricht
@@ -137,7 +163,168 @@ Amazon-Anzeigen-Agenten an. Vier Läufe, kein direkter Kanal, ein Protokoll.
 
 ---
 
-## 5 — Was eine Organisation braucht und ein Agentenhaufen nicht
+## 5 — Eskalation, Konflikt, Beschluss
+
+Der Fall aus dem Vorschlag, Schritt für Schritt:
+
+> Einkäufer A bekommt eine Auftragsbestätigung per Mail und will das Lieferdatum in die
+> Bestellung eintragen. Er findet dafür kein Feld. Er meldet es seiner Teamleitung. Die
+> findet auch keines, hält es aber für wichtig und gibt es an die DevOps-Leitung. Die
+> hält das Feld für überflüssig. **Zwei Abteilungsleitungen sind uneins.** Das muss eine
+> Ebene höher — zum Menschen, oder zu einem CEO-Agenten mit starkem Modell, der selten
+> läuft, aber wichtige Entscheidungen trifft.
+
+Darin stecken drei verschiedene Dinge, die auch drei verschiedene Mittel brauchen.
+
+### Die Voraussetzung: ein belastbarer Negativbefund
+
+„Ich finde kein Feld dafür" muss eine **Feststellung** sein, keine Vermutung. Sonst
+eskaliert die Organisation Einbildungen.
+
+Heute wäre es eine Vermutung. Das Datenbank-Werkzeug kennt genau drei Aktionen —
+`query`, `insert`, `upsert`. Es gibt **keine Möglichkeit, nach dem Schema zu fragen**.
+Auf MySQL käme ein Agent mit `SHOW COLUMNS` durch den SqlGuard (er zählt als lesend),
+aber nichts sagt ihm, dass er das darf; auf SQLite steht `PRAGMA` auf der Verbotsliste,
+dort ist Nachsehen gar nicht möglich. Ein Modell, das die Spalte nicht kennt, rät sie —
+im Testbetrieb nachweislich und wiederholt (#676).
+
+**Ohne Schemaauskunft gibt es die ganze Geschichte nicht.** Sie ist damit Vorbedingung,
+nicht Beiwerk — und mit #676 ohnehin schon gemeldet.
+
+### Eskalation: nach oben, nie zur Seite
+
+Eine **Eskalation** ist: „Ich komme hier nicht weiter, das muss jemand über mir
+entscheiden oder veranlassen." Sie geht immer an die eigene Leitung, nie an einen
+beliebigen anderen Agenten und nie über Ebenen hinweg.
+
+Der Weg fällt damit aus dem Baum heraus, ohne dass ihn jemand konfigurieren muss — das
+ist der Punkt, an dem sich die Struktur auszahlt. Wer eskaliert, kennt nur einen
+Empfänger: seinen Vorgesetzten.
+
+Technisch ist eine Eskalation eine Aufgabe an die Leitung, mit dem auslösenden Vorgang
+als Anhang: Was wurde versucht, was fehlt, was wäre nötig. Die Leitung hat drei
+Antworten: **selbst erledigen**, **zurückgeben** („nimm Feld X"), oder **weiter nach
+oben**.
+
+### Konflikt: entschieden wird beim niedrigsten gemeinsamen Vorgesetzten
+
+Ein **Konflikt** ist etwas anderes: Zwei Einheiten sind uneins, und keine ist der anderen
+weisungsbefugt. Einkauf sagt „das Feld ist nötig", DevOps sagt „ist es nicht".
+
+Die Zuständigkeit fällt wieder aus dem Baum, als eine Regel, die für jedes Organigramm
+gilt:
+
+> **Ein Konflikt wird bei der niedrigsten Stelle entschieden, die beiden Seiten
+> übergeordnet ist.**
+
+Einkauf-Leitung gegen DevOps-Leitung: Die nächste gemeinsame Stelle ist die Spitze —
+also Mensch oder CEO-Agent. Zwei Teams *innerhalb* des Einkaufs: die Einkaufsleitung, und
+niemand darüber wird behelligt. Dieselbe Regel, zwei sehr verschiedene Wege, keine
+Konfiguration.
+
+Ein Konflikt ist ein eigener Vorgang mit beiden Standpunkten, nicht eine Aufgabe, die
+zwischen zwei Abteilungen hin- und herwandert. Wer ihn eröffnet, sagt, worüber gestritten
+wird; beide Seiten bekommen einmal das Wort; die zuständige Stelle entscheidet.
+
+### Beschluss: eine Entscheidung, die nicht hält, wird wieder gestellt
+
+Das ist die Stelle, an der so ein Aufbau normalerweise scheitert. Ist die Entscheidung
+nur eine Antwort in einem Vorgang, dann kommt dieselbe Frage nächste Woche vom nächsten
+Einkäufer — und wird erneut durch vier Ebenen getragen.
+
+Ein **Beschluss** ist deshalb ein eigener, dauerhafter Datensatz: Frage, Entscheidung,
+Begründung, wer entschieden hat, wann, mit welcher Reichweite. Er ist für alles unterhalb
+der entscheidenden Stelle bindend, und er ist auffindbar, bevor eskaliert wird.
+
+Genau dieselbe Bewegung wie zweimal heute: die Dauerfreigabe aus #641 („das musst du
+nicht jedes Mal fragen") und die Dublettenbremse aus #674 („diesen Befund gibt es
+schon"). Eine Organisation, die sich nicht erinnert, was sie entschieden hat, bezahlt
+jede Entscheidung mehrfach.
+
+### Damit es endet
+
+Ohne Regeln läuft so etwas heiß. Vier, die nicht verhandelbar sind:
+
+1. **Nur nach oben.** Ein Vorgang kann nicht zurück nach unten wandern, außer als
+   Entscheidung. Sonst kreist er.
+2. **Jede Stufe kostet.** Eine Eskalation über vier Ebenen sind mindestens vier Läufe,
+   plus ein starkes Modell an der Spitze. Eskalationen gehören gezählt und gedeckelt —
+   und eine Einheit, die alles nach oben reicht, ist selbst ein Befund für die Aufsicht
+   (#680).
+3. **Erst nachsehen.** Vor dem Eskalieren: Gibt es zu dieser Frage schon einen Beschluss?
+   Gibt es den Vorgang schon (#674)?
+4. **Die Spitze ist endlich.** Was der Mensch nicht entscheidet, bleibt offen — sichtbar
+   offen, nicht stillschweigend versandet.
+
+## 6 — Die Entscheidungsinstanz an der Spitze
+
+Der CEO-Agent aus dem Vorschlag ist eine gute Idee mit einer Bedingung: Er ist eine
+**Rolle**, keine Person, und die Rolle muss auch ein Mensch ausfüllen können. Sonst ist
+der Baukasten auf ein Firmenbild festgelegt.
+
+Die Spitze des Baums ist eine Entscheidungsinstanz, und sie lässt sich besetzen mit:
+
+- **einem Menschen** — Vorgänge landen in der Freigabe-Ansicht und warten
+- **einem Agenten** — starkes Modell (etwa Fable 5), läuft selten, entscheidet und
+  begründet
+- **beidem, mit Frist** — der Mensch zuerst; antwortet er binnen einer einstellbaren
+  Zeit nicht, entscheidet der Agent und legt die Entscheidung vor. Für einen Betrieb, der
+  nachts weiterlaufen soll, ist das der interessante Fall.
+
+### Was ein entscheidender Agent darf und was nicht
+
+Ein Modell, das entscheidet, ist etwas anderes als ein Modell, das arbeitet. Deshalb:
+
+- Er entscheidet **Fragen**, er führt sie nicht aus. Aus einem Beschluss wird eine
+  Aufgabe für die zuständige Einheit — er selbst rührt keine Datenbank an.
+- Er hat **kein Werkzeug mit Außenwirkung**. Keine Mail, kein Geld, keine Veröffentlichung.
+- Er **ändert die Struktur nicht**. Agenten anlegen, verschieben, Rechte oder Grenzen
+  heraufsetzen bleibt beim Menschen — Linie von #205, #641 und #687.
+- Er **begründet jede Entscheidung**, und die Begründung steht im Beschluss. Eine
+  Entscheidung ohne Begründung ist für alle darunter nicht anwendbar und für den
+  Menschen nicht überprüfbar.
+
+Und eine Grenze, die man leicht übersieht: **Ein CEO-Agent macht die Organisation nicht
+richtiger, nur schneller.** Er entscheidet Fragen, deren Datengrundlage aus derselben
+Instanz kommt. Was er beschließt, sollte der Mensch stichprobenartig nachlesen — die
+Beschlusssammlung ist dafür genau der richtige Ort.
+
+## 7 — Der Werkzeugkasten
+
+Der Vorschlag nennt es zu Recht in einem Atemzug mit der Struktur: Ein Haus voller
+Agenten ohne Werkzeuge ist eine Konferenz ohne Tagesordnung.
+
+**Was es gibt** (Stand 0.1.15): FileRW, Database, Mail, WebFetch, WebMonitor, DirectAPI,
+FTP, Taskboard, Memory, AgentComm, AgentEditor, AgentSpawn, SocialMediaManager, Telegram,
+RocketChat.
+
+Für den Beispielfall trägt das schon weit: Die Auftragsbestätigung kommt per **Mail**, die
+Bestellung steht in der **Datenbank**, der Marktplatz hängt an **DirectAPI**.
+
+**Was fehlt, ist weniger als es scheint — und etwas anderes.** Die Versuchung ist, fünfzig
+Einzelanbindungen zu bauen: Amazon, eBay, Shopify, DHL, DATEV. Das ist die Falle. Jede
+Einzelanbindung veraltet, und keine trifft die Firma, die als Nächstes kommt.
+
+Der Baukasten braucht stattdessen drei Dinge:
+
+1. **Einen guten generischen Weg nach außen.** DirectAPI gibt es; die offene Frage ist
+   der MCP-Client (#197). Damit hängt jede Anbindung, die es als MCP-Server gibt, ohne
+   eine Zeile Code an der Instanz. Für einen Baukasten ist das die weitaus wichtigste
+   Einzelinvestition — sie ersetzt die fünfzig Anbindungen durch eine.
+2. **Zugangsdaten je Einheit.** Heute hängen sie am Agenten. Ein Einkauf mit sechs
+   Agenten braucht sie einmal, nicht sechsmal — und die Buchhaltung darf den
+   Marktplatz-Schlüssel nicht sehen. Das gehört an die Einheit (#683), mit demselben
+   Vererbungsgedanken wie die Rechte.
+3. **Das Lesen dessen, was wirklich hereinkommt.** Eine Auftragsbestätigung ist ein
+   PDF-Anhang, eine Preisliste eine Tabelle. Text aus Anhängen zu holen ist die
+   unspektakulärste und am häufigsten gebrauchte fehlende Fähigkeit.
+
+Und quer dazu: Jedes neue Werkzeug bringt seine Eignungsproben mit
+([Werkzeugproben-Konzept](Werkzeugproben-Konzept.md), #681). Bei fünfzehn Werkzeugen ist
+das angenehm; bei fünfzig ist es die einzige Art, den Überblick zu behalten, welches
+Modell womit umgehen kann.
+
+## 8 — Was eine Organisation braucht und ein Agentenhaufen nicht
 
 Der Punkt, der beim Bauen am leichtesten übersehen wird: **Eine Organisation lebt von
 gemeinsamem, dauerhaftem Wissen, das in keinem Kopf steckt.**
@@ -160,7 +347,7 @@ Daraus drei Festlegungen:
 
 ---
 
-## 6 — Was sich am Menschen ändert
+## 9 — Was sich am Menschen ändert
 
 Bei fünf Agenten ist der Mensch der Koordinator. Bei fünfzig kann er es nicht sein, und
 der Versuch macht ihn zum Flaschenhals.
@@ -177,7 +364,7 @@ der Versuch macht ihn zum Flaschenhals.
 
 ---
 
-## 7 — Reihenfolge
+## 10 — Reihenfolge
 
 Nichts davon muss auf einmal entstehen. Die Reihenfolge ist so gewählt, dass jede Stufe
 für sich schon nützt und keine die nächste blockiert.
@@ -188,9 +375,16 @@ für sich schon nützt und keine die nächste blockiert.
 | **1** | Einheiten als Struktur: Baum, Zugehörigkeit, vererbte Rechte, Adressbuch nach Einheit | Der Schnitt, der alles Weitere trägt |
 | **2** | Ablage und Brett je Einheit | Buchhaltung und Einkauf treten sich nicht mehr auf die Füße |
 | **3** | Budget und Parallelität je Einheit | Eine ausufernde Abteilung legt nicht die Instanz lahm |
-| **4** | Besprechung als Mittel, mit Protokoll | Leitungen können sich abstimmen, ohne *n²* Nachrichten |
+| **4** | Eskalation, Konflikt und Beschluss (#689) | Eine Frage, die niemand beantworten kann, versandet nicht mehr |
-| **5** | Freigabe durch die Leitung innerhalb von Grenzen | Der Mensch hört auf, Flaschenhals zu sein |
+| **5** | Besprechung als Mittel, mit Protokoll | Leitungen können sich abstimmen, ohne *n²* Nachrichten |
-| **6** | Oberfläche: Organigramm statt Agentenliste, Lage je Abteilung | Bei fünfzig Agenten ist eine flache Liste keine Übersicht |
+| **6** | Entscheidungsinstanz an der Spitze (#690) | Der Betrieb läuft weiter, wenn der Mensch schläft |
+| **7** | Freigabe durch die Leitung innerhalb von Grenzen | Der Mensch hört auf, Flaschenhals zu sein |
+| **8** | Oberfläche: Organigramm statt Agentenliste, Lage je Abteilung | Bei fünfzig Agenten ist eine flache Liste keine Übersicht |
+| **9** | Organisationsvorlagen (#691) | Ein Haus lässt sich weitergeben statt nachbauen |
+
+Quer dazu, unabhängig von der Reihenfolge: der Werkzeugkasten (#692) und die
+Schemaauskunft (#676) — letztere ist Vorbedingung für Stufe 4, weil eine Eskalation
+einen belastbaren Negativbefund braucht.
 
 Stufe 1 ist die einzige, die wirklich weh tut, weil sie Konfiguration, Werkzeuge,
 Arbeitsbereiche und Oberfläche gleichzeitig berührt. Sie zuerst zu bauen ist trotzdem
@@ -199,7 +393,7 @@ wächst, wird der Umzug teurer.
 
 ---
 
-## 8 — Offene Entscheidungen
+## 11 — Offene Entscheidungen
 
 - **Ist eine Einheit ein Agent?** Eine Leitung könnte ein gewöhnlicher Agent mit
   besonderen Rechten sein — oder die Einheit hat eine Leitungsrolle, die auch unbesetzt
@@ -217,7 +411,7 @@ wächst, wird der Umzug teurer.
 
 ---
 
-## 9 — Items
+## 12 — Items
 
 | Item | Vorhaben |
 |---|---|
@@ -226,5 +420,10 @@ wächst, wird der Umzug teurer.
 | #684 | Ablage und Taskboard je Einheit |
 | #685 | Budget und Parallelität je Einheit |
 | #686 | Besprechung: Termin, Tagesordnung, Runde, Protokoll |
+| #689 | Eskalation, Konflikt und Beschluss als eigene Vorgänge |
+| #690 | Entscheidungsinstanz an der Spitze: Mensch, Agent oder beides mit Frist |
+| #691 | Organisationsvorlagen: eine Struktur als importierbare Datei |
+| #692 | Werkzeugkasten: generischer Weg nach außen statt Einzelanbindungen |
+| #676 | Schemaauskunft der Datenbank — Vorbedingung für den Negativbefund |
 | #687 | Freigabe durch die Leitung innerhalb von Grenzen |
 | #688 | Organigramm in Oberfläche und WebUI |