- /api/cases (offen/alle), /api/cases/{id}/decide, /api/cases/{id}/statement, /api/decisions
- Ansicht "Vorgaenge": offene Faelle mit Verlauf je Ebene (Lauf-Links), Frist und
"Mensch gerufen"; Reiter Beschluesse mit Reichweite; Zaehler in der Seitenleiste
- Konzept Abschnitt 5: Umsetzung
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Werkzeugkontext kennt Lauf und Aufgabe des Laufs (RunId, RunTaskId); die
Delegationskette traegt den Lauf des Aufrufers weiter (RunId, CallerRunId)
- Aufgaben tragen origin_run / origin_task (Datei, DB, Taskboard "Arose from"),
gestempelt, nie vom Agenten behauptet
- Kommentare nennen den Lauf, in dem sie geschrieben wurden
- Laufbeleg: CallerRunId; Laufansicht fuehrt zu "Delegiert von" und "Delegiert an"
- #677: task_update ersetzt den Rumpf nicht mehr, Abnahmekriterien aendert nur der
Ersteller; Kommentare der Fremdinhalt-Stufe auf fremden Aufgaben kommen gerahmt an
- WebUI: Herkunft auf der Aufgabenkarte mit Link zum Lauf
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- IAgentTool.ReadsForeignContent: Werkzeuge mit Aussenkontakt erklaeren sich selbst
(WebFetch, WebMonitor, DirectAPI, Mail, RocketChat, Telegram, TelegramClient,
SocialMediaManager, FTP, Database); AgentConfig.TreatAsForeignReader kann nur verschaerfen
- ReportingLine: Stufe aus den Werkzeugen, "wer steht darueber", Pruefung des Wegs nach oben
(nie Aenderungen an Aufgaben darueber, nur eine Ebene hoch, Fremdinhalt-Stufe gar kein
Freitext) und Rahmung als untrusted_content
- Engine: Nachricht und Spawn nach oben geprueft, Text der Fremdinhalt-Stufe kommt gerahmt an
- Taskboard: task_create/update/comment, reopen und die Dubletten-Notiz folgen dem Berichtsweg
- Dispatcher: Aufgaben von Agenten der Fremdinhalt-Stufe gehen gerahmt in den Lauf
- TaskReports: Erledigt-Signal und Systemmeldung (in Pruefung, blockiert, abgebrochen) an den
Auftraggeber, je Zustand einmal, gesammelt in einer offenen Aufgabe je Empfaenger
- OrgBriefing nennt den Berichtsweg; WebUI zeigt Stufe und Schalter am Agenten
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- TaskBoard: das Brett einer Aufgabe wird nicht gespeichert, es folgt aus
der Organisation - Einheit des Zustaendigen, sonst des Anlegers. Offene
Aufgaben ziehen damit beim Umzug mit. Sichtbar: das eigene Brett, fuer eine
Leitung alle darunter, und was man selbst angelegt hat (nach oben
Gereichtes bleibt im Blick).
- TaskItem.CreatedBy, in der Datei als created_by und in der DB. Ein Import
aus einer Datei ohne das Feld behaelt, was die DB weiss.
- Taskboard-Tool: task_list, task_find und die Dublettenpruefung sehen nur
die eigenen Bretter - eine aehnliche Buchhaltungsaufgabe haelt keine
Marketingaufgabe auf und bekommt keinen Kommentar von dort. task_update und
task_comment antworten auf eine fremde Aufgabe wie auf eine unbekannte.
- TaskboardService.ListAsync mit Sichtfilter: erst filtern, dann kappen.
- WebUI: jede Aufgabe nennt ihr Brett, ein Filter waehlt eines aus.
- Konzept (Abschnitt 3) und Einrichtungshandbuch nachgetragen.
Ohne Einheiten aendert sich nichts - ein Brett fuer alle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rueckmeldung zur Teamuebersicht: wirkte veraltet, und die Verbindungen
zwischen den Einheiten fehlten - zugeklappte Container versteckten ganze
Ebenen, man haette sich bis zum Problem durchklicken muessen.
- Jede Einheit ist immer eine Karte, verbunden als Organisationsbaum
(ELK layered, orthogonale Linien, eckige Anschluesse). Keine Ebene wird
versteckt. Zugeklappt wird nur die Agentenliste grosser Einheiten: sie
zeigt, wer Aufmerksamkeit braucht, und "+n weitere".
- Eine Linie traegt die Farbe des dringlichsten Zustands darunter - eine
rote Linie fuehrt von oben zum Problem.
- Links ein Strukturbaum mit Suche (Agent, Einheit, Modell) und
Zustandsfilter; Treffer werden hervorgehoben, der Weg dorthin geoeffnet,
der Rest abgeblendet. Enter springt zum ersten Treffer.
- Leinwand mit Punktraster, Verschieben und Zoomen, schwebende Leisten
(Live-Verbindungen, Einpassen, Zoom). Live-Verbindungen laufen von Zeile
zu Zeile, gebuendelt mit Zaehler.
- Hausstil bleibt (Radius 0, App-Akzent), hell und dunkel, bis Handybreite.
- Cytoscape und cytoscape-elk entfernt: ein Canvas-Knoten kann keine
Agentenliste, Suche oder den Hausstil tragen. Karten sind jetzt HTML.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- TaskSchedule.OccurrencesBetween zaehlt, wie oft eine Aufgabe bis zu einem
Zeitpunkt noch laeuft, einschliesslich eines jetzt faelligen Laufs.
- BudgetHeadroom (ILateRunGate): Ein mitgenommener oder nachzuholender Lauf
startet nur, wenn er in den Spielraum passt: Grenze minus Verbrauch minus
Reservierung minus Bedarf der restlichen geplanten Laeufe bis Mitternacht
minus 10 % Reserve. Das gilt je Agent und je Instanz, fuer Kosten und Tokens.
Anderes Spaetwerk zaehlt nicht als Bedarf, sonst blockierten sich
mitgenommene Aufgaben gegenseitig.
- Der Scanner fragt den Spielraum nur fuer Spaetwerk und protokolliert, wenn es
warten muss. Die Engine gibt ihren BudgetGuard heraus, damit Scanner und
Engine dieselben Reservierungen sehen.
- Ersetzt den pauschalen 25-%-Anteil aus dem Konzept (dort nachgezogen): Ein
fester Anteil ist an vollen Tagen zu viel, an ruhigen zu wenig.
Drei weitere stille Kappungen bei 500 beseitigt (ListAllAsync, ungekappt):
Kostenprognose (Aufgaben ueber 500 fehlten), Waisenabgleich beim Import und
task_find aus #674, wo Dubletten unter aelteren Aufgaben mit niedriger
Prioritaet unsichtbar wurden.
Tests: BudgetHeadroomTests (9), Scanner-Pforte (1), Dublette hinter 500
Aufgaben (1). 1.257 gruen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Zeitlich flexible Arbeit mit Frist statt Termin fuellt ungenutztes Tagesbudget
(Backfilling); ob Platz ist, entscheidet der Code aus Restbudget und Prognose.
Grossaufgaben werden geteilt oder bekommen ein vom Menschen freigegebenes
Sonderbudget als eigenen Topf.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 8a: Was liegen bleibt, wenn das Budget endet. Ist-Zustand nachgesehen
(einmalige Aufgaben werden still nachgeholt, wiederkehrende verfallen still),
Vorschlag expire / catch_up_once / carry_over je Agent, der neue Tag hat
Vorfahrt, Vermerk an der Aufgabe und als Tageszusammenfassung, Vorbeugen
ueber die Prognose aus #608, Budgetreservierung als Rest aus #682.
- 3: Festlegung des Nutzers, dass Einheiten keine eigene Konfiguration
speichern; Einstellungen fuer eine Einheit werden gesammelt in die Agenten
geschrieben. Drei Kollisionen als offen markiert: Rechte-Obergrenze,
Parallelitaet je Einheit, Grenzen der Leitung.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 7a Fremde Laufzeiten: Claude Code u. a. als Laufzeit der
Entwicklungsabteilung; gilt als weniger vertrauenswuerdig (Worktree/
Sandbox, Freigabelisten statt Rechte-Umgehung, Ergebnis ist ein Vorschlag,
nach aussen nur ueber den ClawdDotNet-MCP-Server). Vorbehalte Kontingent
und Nutzungsbedingungen als offene Entscheidung.
- 9a Von Paperclip gelernt: Zielkette mit Pruefung ruhender Aufgabenbaeume,
Rueckmeldung nach Vertrauensstufe (fremder Text steigt nicht in der
Hierarchie auf), Courier Pattern; bewusst nicht uebernommen: Rechte-
Umgehung als Voreinstellung, firmenweite Sichtbarkeit.
- 10a Das Lagebild: Teamuebersicht mit Layout aus der Struktur,
aufklappbaren Einheiten, Problemzustaenden aus dem Code und Seitenleiste
vor dem Chat; Stufe 0 ohne Einheiten.
- Reihenfolge, offene Entscheidungen und Itemliste nachgezogen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Abstimmung zaehlt keine Meinungen, sondern erzwingt unabhaengige
Pruefungen aus verschiedenen Datenquellen. Daraus folgt die Regel, an der
alles haengt: Es wird BLIND abgestimmt. Sieht ein Stimmberechtigter die
Stimme eines anderen, stimmt ein guenstiges Modell dem zu, was es gerade
gelesen hat - aus vier Pruefungen werden eine und drei Echos. Damit ist die
Abstimmung das Gegenstueck zur Besprechung, wo jeder die Beitraege sieht.
Und eine Kehrtwende bei #700: Vorgeschlagen war eine Frist mit Kehrbesen
fuer Audit und Receipts. Richtig ist das Gegenteil. In einem Buero voller
Menschen geht taeglich verloren, warum etwas so entschieden wurde - hier
nicht. Bei hundert Agenten sind es 3,3 GB im Jahr; dafuer wirft man kein
Wissen weg. Was bleibt, ist ein Archiv: heiss und kalt trennen, verdichtete
Werte immer behalten, Geheimnisse gar nicht erst hineinschreiben, gezielt
loeschen koennen.
Folge: Die 14-Tage-Voreinstellung der Prompt-History gehoert auf unbegrenzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Der Baum ist beliebig tief schachtelbar, und Einheiten wie Agenten muessen
sich nachtraeglich verschieben lassen - bei gestoppter Instanz, mit
Unterrichtung der Betroffenen und Eintrag im Audit. Das Konzept setzte das
schon voraus ("wer mehr Reichweite geben will, verschiebt im Baum"), ohne es
je zu beschreiben.
Beim Gegenlesen gefunden und aufgeloest:
- "Nur nach oben" gegen "zurueckgeben": Die zweite Antwort der Leitung ist
eine ENTSCHEIDUNG, die den Vorgang schliesst. Verboten ist der ungeloest
zurueckwandernde Vorgang.
- Konflikt gegen "nie ueber Ebenen hinweg": Ein Konflikt klettert nicht, er
wird zugestellt. Die Zustaendigkeit ergibt sich rechnerisch aus dem Baum;
dazwischenliegende Ebenen werden vermerkt, nicht befragt.
- Die Ausnahmen von "ein Agent kennt nur seine Einheit" stehen jetzt
vollstaendig beisammen - vier, alle lesend, keine gibt einen neuen
Gespraechspartner. Verstreute Ausnahmen vermehren sich.
- Stale Verweis "Vorbedingung fuer Stufe 4" auf Stufe 5 berichtigt, die
Kontrollpflicht vor die Oberflaeche gezogen.
Vier Punkte als zu grob markiert und mit Vorschlag versehen: Budget als
Deckel oder Zuteilung, woraus eine Freigabegrenze besteht, wie ein
Beschluss wirksam wird, was die Eskalationsgrenze tut, wenn sie greift.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Meldung, die vier Ebenen durchlaeuft, wird viermal neu formuliert.
Das faellt nicht auf, weil es keinen Fehler gibt, den man finden koennte -
alle arbeiten korrekt, und die Spitze entscheidet ueber eine Nacherzaehlung
der Nacherzaehlung.
Die Regel: Jede Weitergabe haengt an, sie ersetzt nicht. Der Verweis auf
den Ursprung wandert mit, der Inhalt bleibt liegen und wird geholt, wer ihn
braucht. Eine Zusammenfassung darf danebenstehen, nie anstelle. Dieselbe
Festlegung wie beim Aufgabenrumpf (#677), hier fuer den Weg.
Beim Skriptfehler heisst das: Der Sandbox-Runner legt Exit-Code, stderr,
Aufrufparameter, Dauer und RunId unter scripts/<id>/fehler/ ab - nicht der
Agent. Der Zugang folgt dem Skript statt der Abteilung, damit der
Entwickler alle Fehlschlaege seines Werkzeugs sieht, ohne in fremde
Arbeitsbereiche zu duerfen. Durch die Befehlskette geht nur noch der
Verweis.
Nebenbei zwei doc_anchors nachgezogen, die durch fruehere Umnummerierung
ins Leere zeigten (#687, #688).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Korrektur der gestrigen Fassung: Dort stand, der zustaendige Agent schreibe
und pflege sein Skript selbst. Ein Anzeigen-Agent, der programmiert und
beliebigen Code ausfuehrt, hat Rechte, die seine Arbeit nicht braucht.
Die Lieferkette: Bedarfsmeldung mit ausgearbeiteter Beschreibung an die
eigene Leitung, von dort an die Entwicklung, dort schreiben und testen,
Pruefung und Freigabe nach #657, Zuteilung an genau diesen einen Nutzer.
Fehler gehen ueber dieselbe Kette zurueck.
Technisch folgt daraus, dass scripts.run kein Schalter sein darf, sondern
eine Liste benannter Skripte - ein Ja/Nein waere die Hintertuer, die die
Trennung gerade schliesst.
Und ein zweiter Gewinn, der als Entwurfsziel gelten soll: Der Agent, der
fremde Inhalte liest, ist nie der Agent, der ausfuehrbaren Code
hervorbringt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Korrektur der vorigen Fassung: Plattformen werden NICHT angebunden, auch
nicht als MCP-Server je Plattform - das verlagert die Pflege nur nach
aussen. Das Produkt gibt Faehigkeiten (API, Webseite, Datenbank, Mail); was
spezifisch ist, schreibt sich die Instanz selbst. Damit sind Sandbox (#654),
Shell (#196) und Skriptpruefung (#657) nicht nur Sicherheitsvorhaben,
sondern der eigentliche Werkzeugkasten. Die Reihenfolge bleibt zwingend:
erst die Sandbox, dann das Schreiben.
Neu: Eine Leitung delegiert nicht nur, sie prueft stichprobenartig (#693) -
gegen AuditLog und Transkripte, nie gegen die Selbstauskunft, denn ein
Modell hat am 14.09. dreizehn Werkzeugantworten erfunden. Aus einem Befund
folgen abgestufte Mittel: meist ein schaerferer Auftragstext, seltener ein
anderes Modell, zuletzt Stilllegung. Vorgeschlagen von der Leitung,
ausgefuehrt nach Freigabe.
Dazu der A/B-Vergleich im Betrieb (#694), gemessen an Dingen, die das
Modell nicht selbst behauptet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Die Regel im InstanceSetupGuide war in der Beobachtung richtig und in der
Folgerung falsch: quadratisch steigen die Verbindungen, nicht die Agenten.
Ein Agent, der drei Nachbarn und eine Leitung kennt, kostet gleich viel, ob
die Instanz zehn oder hundert Agenten hat.
docs/Organisation-Konzept.md haelt fest, was heute bei 50 Agenten bricht
(flaches Adressbuch, synchrones send_message, Delegationstiefe 3,
unbegrenzte Parallelitaet, Kappung bei 500, zwei Arbeitsbereiche, ein Brett,
zwei Budgetebenen, eine Freigabe-Warteschlange) und schlaegt die fehlende
Ebene vor: die Einheit.
Zwei davon sind schon heute Fehler und gehoeren sofort behoben (#682).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
