- 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>
Der offene Rest aus #682: Jeder Lauf pruefte das Budget einzeln gegen den
bisher erfassten Verbrauch. Laufende Laeufe waren unsichtbar, gleichzeitig
startende passierten die Pruefung gemeinsam und ueberzogen gemeinsam.
- BudgetGuard.ReserveAsync prueft und reserviert unter einer Sperre. Die
Reservierung ist der Mittelwert der letzten 20 Laeufe des Agenten (Laeufe
ohne Verbrauch zaehlen nicht mit) und gilt, bis der Verbrauch des Laufs
erfasst ist.
- Gegen die Grenze zaehlt: verbraucht + in laufenden Laeufen reserviert. Die
eigene Schaetzung eines Laufs zaehlt bewusst nicht mit; ein einzelner Lauf
wird weiter nur abgelehnt, wenn das Budget schon verbraucht ist. Sonst fiele
eine kleine Aufgabe wegen eines grossen Durchschnitts aus.
- Gilt fuer Kosten- und Tokengrenze, je Agent und je Instanz.
- Die Ablehnungsmeldung nennt den reservierten Anteil, sonst wirkte "0,60 von
1,00 USD verbraucht" als Ablehnungsgrund falsch.
- IUsageRepository.GetRecentForAgentAsync, mit leerer Vorgabe im Interface,
damit bestehende Attrappen unberuehrt bleiben.
Tests: BudgetReservationTests (8 neu), darunter zehn gleichzeitige Starts, von
denen genau vier passieren. 1.246 gruen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher teilte sich eine Budgetablehnung den Ausgang NichtGelaufen mit dem
Herunterfahren. Einmalige Aufgaben wurden den Rest des Tages alle 30 Minuten
erneut abgelehnt (jedes Mal ein Beleg) und liefen nach Mitternacht still zu
Lasten des neuen Tages. Wiederkehrende verfielen still.
- TaskLauf.KeinBudget als eigener Ausgang; der Dispatcher bildet
BudgetExceeded darauf ab.
- Vier Felder an der Aufgabe: BudgetMissCount, LastBudgetMissAt,
DeferredUntil, CatchUpPending (Spalten werden fuer bestehende Datenbanken
nachgeruestet).
- Einmalige Aufgaben werden mitgenommen: Der Termin bleibt erhalten, faellig
ist die Aufgabe wieder ab der naechsten lokalen Mitternacht, nicht vorher.
- Wiederkehrende Aufgaben folgen der Regel des Agenten
(budget.whenExhausted): expire vermerkt den Ausfall und laesst den Termin
verfallen; catchUpOnce fasst alle verpassten Termine zu einem Nachholauf am
naechsten Tag zusammen. Ein regulaer faelliger Termin deckt das Nachholen
mit ab, es bleibt bei einem Lauf.
- Der neue Tag hat Vorfahrt: Mitgenommenes und Nachholaeufe kommen nach allem
regulaer Faelligen, unabhaengig von der Prioritaet.
- Beim ersten Takt eines neuen Tages eine Zusammenfassung je Agent im Log.
- Sichtbar: Die Aufgabenkarte der WebUI zeigt Ausfaelle, Mitnahme und
Nachholen; die Regel ist im Desktop je Agent einstellbar. Nebenbei sind
"Next:"/"Last:" auf der Karte ins Sprachpaket gewandert.
Stufen 2 bis 4 (Reservierung, Spielraum statt pauschalem Anteil, Vorbeugen)
folgen.
Tests: BudgetMissTests (9 neu). 1.238 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>
Drei Fehler im Taktgeber des Taskboards, zwei gemeldet, einer beim Bau gefunden:
1. Unbegrenzte Parallelitaet. Jede faellige Aufgabe startete sofort. Bei
Cron-Terminen auf runden Zeiten hiess das: alle Agenten gleichzeitig, und
alle Laeufe passierten die Budgetpruefung gemeinsam, weil sie je Lauf vor
dem Start laeuft. Neu: maxParallelTaskRuns je Instanz (Vorgabe 4). Der Rest
wartet, sortiert nach Prioritaet und dann nach Faelligkeit.
2. Stille Kappung. Die Kandidaten kamen ueber ListAsync mit Limit 500; darueber
fielen Termine lautlos aus dem Takt. Neu: ListRunnableAsync liefert alle
Aufgaben auf todo, ungekappt. Muessen Aufgaben warten, steht das im Log,
allerdings nur, wenn sich die Zahl aendert.
3. Der Takt wartete auf jeden Lauf, den er startete. Ein zehnminuetiger Lauf
hielt damit jeden anderen Termin zehn Minuten an, und mit einem Deckel
haetten die freien Plaetze leer gestanden. Neu: Die Schleife startet und
wartet nicht; DisposeAsync wartet stattdessen auf die laufenden Laeufe.
Beansprucht wird nur, was sofort starten kann. Alles andere bleibt auf todo,
sonst liefe beim Warten der Lease ab und die Aufgabe wuerde ein zweites Mal
beansprucht. Ein Cron-Termin geht dadurch nicht verloren, weil DueOccurrence
bis zum letzten Lauf zuruecksucht. Ein von Hand gestarteter Lauf wartet auf
keinen Platz, belegt aber einen.
Bleibt offen: Bis zu maxParallelTaskRuns Laeufe koennen die Budgetpruefung
weiterhin gemeinsam passieren. Die Luecke ist damit begrenzt, aber nicht
geschlossen; dafuer braeuchte es eine Reservierung vor dem Lauf.
Tests: ScannerCapacityTests (9 neu). 1.229 gruen.
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>
Umbau durch Gemini Flash, Durchsicht und Nacharbeit durch Claude.
Umfang:
- Desktop: LocalizationManager (JSON-Pakete, Rueckfall auf Englisch,
Umschalten zur Laufzeit), Localize-Markup-Erweiterung, Sprachwahl in den
Einstellungen (AppSettings.Language, Vorgabe "en"); 317 Schluessel je Sprache
- WebUI: alle Ansichten auf t()/data-i18n, 656 Schluessel je Sprache
- Agenten-Werkzeuge: Beschreibungen, Schemata und Meldungen auf Englisch
- Tests an die englischen Meldungen angepasst, keine Pruefung abgeschwaecht
Nacharbeit bei der Durchsicht:
- ~25 Kommentarbloecke mit Begruendungen waren ersatzlos entfallen, darunter
sicherheitsrelevante (NTFS-Datenstrom beim shared:-Praefix, Bremse gegen
Agentenschleifen, doppelter POST beim Anlegen einer Instanz). Wieder
eingesetzt: auf Englisch, wo die Datei umgestellt ist, sonst im Wortlaut.
- Drei WebUI-Schluessel fehlten (logs.paused, instances.instanceOfflineError,
instances.noInstanceActiveError). Weil t() bei fehlendem Schluessel den
Schluessel selbst liefert, griff der "|| err.message"-Rueckfall nie — die
Oberflaeche haette den Schluesselnamen angezeigt.
Geprueft: Schluesselgleichheit en/de, Platzhalter je Schluessel, jeder im
Code benutzte Schluessel vorhanden, node --check fuer alle Module,
1.220 Tests gruen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Aus dem Dauerbetrieb der Testinstanz entstanden, 0.1.11 bis 0.1.15:
Freigaben und Aufgaben
- Freigaben werden gebuendelt statt einzeln geweckt (#643); das Freigabemodell
liegt in den Werkzeugrechten des Agenten (#641), Dauerfreigaben inklusive.
- Sammel-Lesen fuer FileRW (#663) und der Hinweis auf den anderen Workspace
(#662) - beide aus Laeufen, die an der Schrittgrenze starben.
- list sortiert, deckelt und nennt die Gesamtzahl (#673). Die Betriebskontrolle
hatte vorhandene Dateien als fehlend gemeldet, weil 105 Eintraege unsortiert
ankamen. Dabei fiel auf, dass ein Suchmuster aus dem Verzeichnis herausfuehren
konnte (#675).
- task_find und eine Dublettenbremse (#674): derselbe Befund ist keine zweite
Aufgabe.
Sichtbarkeit
- Prompt-History mit Aufbewahrung je Agent und Verbrauchsauswertung (#660).
Sie hat #673 gefunden - erster Nutzen am zweiten Tag.
- Englisch als Hauptsprache neuer Module, Texte ueber Sprachpakete (#661).
Konzepte, noch nicht gebaut
- docs/Organisation-Konzept.md: Einheiten, Eskalation, Konflikt und Beschluss,
Besprechung, Abstimmung, Doctrine, Kostenanalyse je Einheit. Die Regel
"hoechstens fuenf Agenten" ist zurueckgezogen - quadratisch steigen die
Verbindungen, nicht die Agenten.
- docs/Basisagenten-Konzept.md, docs/Werkzeugproben-Konzept.md.
- docs/Security-Konzept.md um die Zugangsdatenverwaltung ergaenzt und erstmals
versioniert.
Offen und vorgemerkt: #682 (Parallelitaet deckeln, stille Kappung), danach die
Einheiten aus dem ORG-Block.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Begruendung zum Vergleich vom 2026-09-18 (OpenClaw 2.0, Grok Bot) lag
unversioniert im Arbeitsbaum, zusammen mit der erzeugten Kopie vom
2026-09-19. Beides gehoert ins Repository - die Begruendung, weil sie von
Hand geschrieben ist und bleibt, die Kopie, weil sie den Stand zeigt.
Der Block zwischen den dc:roadmap-Markern bleibt erzeugt und wird beim
naechsten Lauf ueberschrieben; die heute angelegten Items #673 bis #704 sind
darin noch nicht enthalten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Agent schickt Platzhalter, ClawdDotNet setzt sie im Werkzeug ein. Der
Ansatz ist richtig, loest aber weniger als er verspricht - die sieben
Luecken dazwischen sind die Arbeit. Die beiden wichtigsten: Ersetzt wird an
benannten Stellen je Werkzeug, nie als Suchen-und-Ersetzen ueber alle
Argumente; und jedes Geheimnis wird an ein Ziel gebunden, sonst schuetzt der
Platzhalter den Wert vor dem Modell und liefert ihn an den Angreifer.
Die Datei lag bisher unversioniert im Arbeitsbaum, obwohl fuenf Items
(#651-#659) ueber doc_anchor auf sie verweisen. Damit war die Begruendung
fuer niemanden ausserhalb dieses Rechners lesbar - genau das, was die
Regeln in CLAUDE.md verhindern sollen.
Co-Authored-By: Claude Opus 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>
Zwei Nutzervorschlaege aus dem Testbetrieb, beide mit Ankern im Bestand:
Die Aufsicht ist das dritte Profil des AgentInspector (#204), neben dem
Security-Profil (#658); die Werkzeugproben fuellen Stufe 2 des Probelaufs
fuer neue Agenten (#649) und loesen den "Evals-Test-Runner" aus dem
Orchestrator-Konzept ein.
Zwei Entscheidungen tragen die Dokumente:
- Erkennen ist Code (#646), Deuten ist Modell (#680). Wer das verwischt,
bezahlt ein Sprachmodell fuers Zeilenzaehlen.
- Die Eignungsprobe gehoert zum Werkzeug, nicht in eine zentrale Liste,
und wird gegen das Audit geprueft, nie gegen die Selbstauskunft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Betriebskontrolle im Testbetrieb meldete Stundendateien als fehlend, die
es gab: 105 Eintraege in der Reihenfolge des Dateisystems, vierzeilig als
eingeruecktes JSON. list liefert jetzt die 50 zuletzt geaenderten Eintraege,
neueste zuerst, eine Zeile je Eintrag, mit Gesamtzahl im Kopf; pattern, sort,
order und limit steuern das.
Dabei aufgefallen (#675): Directory.GetFiles wertet Trennzeichen im Muster
aus - pattern "../*" fuehrte an der Pfadpruefung vorbei aus dem Verzeichnis
heraus, in list wie in read_many. Muster mit '/', '\' oder '..' werden jetzt
abgewiesen.
Und derselbe Befund ist keine zweite Aufgabe (#674): task_find beantwortet
die Frage vor dem Anlegen, task_create legt bei gleichbedeutendem Titel einer
offenen Aufgabe keine zweite an, sondern vermerkt das erneute Auftreten an
der bestehenden. force=true geht trotzdem, Erledigtes blockiert nichts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#663: Neue Aktion read_many liest mehrere Dateien in einem Aufruf - entweder
paths (Liste) oder path (Verzeichnis) mit pattern. Gedeckelt auf 50 Dateien und
200.000 Zeichen; was nicht mehr hineinpasst, wird namentlich genannt, damit der
Agent gezielt nachholen kann. Anlass: Der Tagesabschluss im Testbetrieb las 24
Stundendateien einzeln und starb zweimal an der Schrittgrenze - die soll
Endlosschleifen abfangen, nicht ehrliche Arbeit.
#662: Schlaegt read oder list fehl, weil der Pfad im anderen Workspace liegt,
sagt die Fehlermeldung das - aber nur, wenn der Agent diesen Workspace auch
benutzen darf. Guenstige Modelle vergassen workspace "shared" regelmaessig und
verbrauchten mit jedem Rateversuch einen Schritt.
Dateipruefung, Endungen und Workspace-Grenze gelten in read_many unveraendert;
eine verbotene Endung wird uebergangen statt den Lauf zu kippen.
Version 0.1.14.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Prompt history: every run records its transcript (task, each model step with
tokens and cost, tool calls and results, engine follow-ups) - bounded in size,
scrubbed of recognisable secrets, system prompts stored once per text.
Retention in days per instance (default 14) and per agent (0 = never, -1 =
forever); an hourly janitor deletes what is past it, "never" also purges.
Usage analysis over run receipts: filter by period, agent, model, event, status,
cost and free text; sort by every column; totals over the whole filter; hourly
or daily series grouped by agent, model or event; markers for budget denials and
model changes; run detail with receipt, transcript, tool calls and approvals.
WebUI: Analysis > Token usage > Runs / Timeline, run detail, Prompt History with
retention settings. New code, comments and texts in English; texts come from
language packs (i18n/en.json, de.json) via modules/i18n.js. CLAUDE.md records
English as the main language.
Version 0.1.12.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#643: Entscheidungen wecken den Agenten nur noch bei Ablehnung oder gescheiterter
Ausfuehrung, gesammelt in einer Aufgabe je Agent (5 min Ruhefenster), frisch per
@new:agent statt im fortgefuehrten Chatverlauf. Eine einmalige Aufgabe, deren Lauf
wegen Budget oder Herunterfahren gar nicht stattfand, bleibt faellig (Wiedervorlage
nach 30 min) statt mit gesetztem Marker liegenzubleiben.
#641: Rechte stehen in der Werkzeugkonfiguration des Agenten (erlaubt/verboten).
Erlaubtes laeuft, Nicht-Erlaubtes wird einzeln vorgelegt statt verweigert, Verbotenes
gar nicht erst. "Gleichartiges kuenftig erlauben" erteilt eine widerrufbare
Dauerfreigabe je Agent/Werkzeug/Operation; nach drei gleichartigen Freigaben schlaegt
die Oberflaeche sie vor. Aenderungen an Agenten bleiben ausnahmslos freigabepflichtig.
Database: Operation ist das SQL-Schluesselwort; die eigene Zugriffspruefung greift nur
noch ohne Freigabestelle (AgentToolContext.FreigabeGeprueft). WebUI: Rechte-Tabelle je
Werkzeug, Dauerfreigaben mit Widerruf.
Version 0.1.11.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#631: Derselbe Vorschlag (gleicher Agent, gleiches Werkzeug, gleiche Argumente unabhaengig
von Schluesselreihenfolge) wird nicht erneut angelegt - der Agent erfaehrt die bestehende
Nummer. Offene Vorschlaege verfallen nach 24 h (Status Expired).
#609: Werkzeuge koennen den Freigabeschluessel aus dem Inhalt bestimmen
(IAgentTool.StagingAktion). Database: SELECT/SHOW/DESCRIBE -> query, INSERT/UPDATE/DELETE
-> write, DDL -> schema; write und schema sind freigabepflichtig. Ausgefuehrt wird nach
Statement-Art, schreibende Statements melden die Zeilenzahl.
#579: Database-Vorpruefung (Zugriffsebene, Tabellenfreigabe, SqlGuard) - was das Werkzeug
ablehnen wuerde, kommt nicht mehr in die Freigabeliste.
#610: SqlGuard ueberspringt IF [NOT] EXISTS und erkennt DESCRIBE/DESC <tabelle>.
#632: WebFetch fetch mit filter liefert aus JSON/JSONP nur passende Eintraege; beim
Blaettern durch grosses JSON empfiehlt der Hinweis den filter.
Version 0.1.10.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#608: Ein wegen erschoepften Budgets abgelehnter Lauf hinterlaesst jetzt einen Beleg
(Status BudgetExceeded) an Aufgabe und Verlauf; die Log-Warnung kommt einmal je Agent,
Grenze und Tag. Die Kostenprognose zaehlt Ablehnungen nicht als Lauf und warnt, wenn die
geplanten Aufgaben eines Agenten sein Tagesbudget uebersteigen (API + Verbrauchsansicht).
#607: Passt schon der erste Treffer nicht in den Abruf, wird er gekuerzt (Anfang und Ende
bleiben) statt ganz zu fehlen. remember weist auf gleichnamige Eintraege ohne Schluessel und
auf Eintraege nahe der Abrufgrenze hin.
Version 0.1.9.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im Dauerbetrieb lief die Kompaktierung bei jedem Schritt an und blieb wirkungslos:
Stufe 1 pruefte mit der rohen Schaetzung, kompaktierte nur knapp unter die Schwelle
und brach dabei jedes Mal den Prompt-Cache; der Zusammenfassungs-Aufruf fehlte im
Verbrauch. Ziel jetzt min(Schwelle, 55 % des Limits), Usage des Aufrufs geht in den Lauf.
Version 0.1.8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- HtmlExtraktor (AngleSharp): Selektor > article (>= 40 % des Seitentexts) > main > Textdichte,
Seitenrahmen und Stoerbloecke entfernt, Ueberschriften/Listen/Tabellen/Code als Markdown,
Linkziele nur mit links=true, Metadaten (Titel, Sprache, kanonische URL, Datum)
- WebInhalt: JSON/Text/XML unveraendert, Rueckfall auf Volltext bei zu wenig Hauptinhalt,
mode=full, nextOffset fuer lange Inhalte, JSON kompakt ohne Unicode-Escapes
- RSS: limit, Beschreibungen gekappt; dataAsOf nicht mehr aus dem Date-Header
Gemessen: tagesschau-Artikel 16.000 (abgeschnitten) -> 9.635 Zeichen vollstaendig.
Version 0.1.7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Engine: leere Antworten nachfassen, Aufgaben enden mit Ergebniszeile (EmptyResponse/Incomplete),
gleiche Fehlschlaege erkennen (RepeatedFailure), Zeitzeile vor Chatnachrichten,
Werkzeugergebnisse gerahmt, Vorpruefung vor dem Staging, Belegkosten wie RunUsage
- Staging: gescheiterte Freigaben als Failed; AgentEditor-Aenderungen freigabepflichtig,
Selbstbearbeitung gesperrt (allowSelfEdit)
- Taskboard: Termine beim Anlegen pruefen, naechster/letzter Lauf, pausieren, Sofortlauf,
Kostenprognose, Hinweis auf wachsenden Kontext; Jobs-Reiter und /api/jobs entfernt
- Release: Instanzmanager samt Weboberflaeche im Paket, setup.json fragt manager.json ab,
Token nicht mehr ins systemd-Journal
Version 0.1.6.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Nachrichten-Digest im Dauerbetrieb der Test-VM lief nie: CronExpression
verstand 'von-bis/schritt' nicht, TaskSchedule verschluckte den Fehler.
Version 0.1.5.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- #578: Abgebrochene Laeufe (Schrittgrenze, Zeitueberschreitung, Abbruch,
Ausnahme) tragen ihre bezahlten Token - vorher 0 in RunUsage, fuer das
Budget unsichtbar.
- #580: WebFetch prueft die aufgeloeste Zieladresse beim Verbinden; ein
erlaubter Name, der auf 127.0.0.1 aufloest, wird gesperrt.
- #575: Dateien entstehen unter Unix mit 0600 (AtomicFile, Protokolle,
FileRW-Anhaengen, state.db), Protokollverzeichnisse mit 0700.
- #576: SIGTERM/SIGINT beenden auch mit Fenster geordnet.
- #593: OpenRouter-Statusdienst wird gestartet.
- #589: Auftragsnachricht nennt aktuelle Zeit, Zeitzone und Termin.
- #581: Unvollstaendiges Argument-JSON erreicht das Werkzeug nicht mehr;
das Modell bekommt eine verstaendliche Rueckmeldung statt Parsertext.
- #591: Weboberflaeche liest die Felder, die API und Ereignisstrom liefern
(Freigaben, Protokoll, Taskboard mit Termin, Werkzeug-Einstellungen,
Tokennutzung); Ereignisstrom in camelCase.
- #592: Chat zeigt Nachrichten nicht mehr doppelt.
- #536 (teilweise): A2A-Antworten tragen Absender und Empfaenger, Parser
wirft nicht mehr; Datums- und Volltextfilter in Agenten-Chats.
- deploy/publish.py: Packager-Pfad net10.0, Schalter --agent-file.
- Version 0.1.4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AppHost.StartAsync ruft jetzt CrashRecovery. Ein geordnetes Ende
hinterlaesst nichts; ist etwas da, ist die Instanz gestorben, waehrend
Werkzeuge liefen.
Bewusst nur sichten und protokollieren, nicht ausfuehren. Ob die Wirkung
eines Aufrufs eintrat, weiss auch dieser Dienst nicht - ein automatisches
"dann eben nochmal" versendete im Zweifel die Mail ein zweites Mal.
Scheitert die Sichtung selbst, haelt sie den Start nicht auf. Eine
Instanz, die wegen einer misslungenen Nachschau nicht hochkommt, waere
schlimmer als eine, die mit einer Wissensluecke startet.
Der Aufruf sitzt in StartAsync statt in BuildCore: BuildCore ist synchron,
und die Signatur zu aendern haette durch alle Aufrufer gezogen. Blockendes
Warten in einer Fensteranwendung waere die schlechtere Loesung gewesen.
Build ohne Warnungen, 912 Tests, keine Regression.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
#553 FileRW schreibt atomar. Die Vorkehrung lag seit #241 im selben
Repository und wurde ueberall benutzt - Einstellungen, Sicherungen,
Chat-Zustand, Identity.md - nur der Weg, ueber den Agenten ihre
Arbeitsergebnisse ablegen, ging daran vorbei. Damit stand das Verhaeltnis
auf dem Kopf: geschuetzt war das Eigene, ungeschuetzt das Ergebnis.
append bleibt bewusst nicht atomar; das ginge nur, indem die ganze Datei
neu geschrieben wird, und bei einer grossen Protokolldatei waere das der
falsche Handel.
#554 Wiederaufnahme. Neuer Eintrag AuditStatus.Started, geschrieben VOR
der Wirkung und als einziger nicht "best effort" - auf ihn stuetzt sich
alles Weitere, also laeuft der Aufruf gar nicht erst, wenn er nicht
durchkommt. Neue Kennzeichnung IsRepeatable, getrennt von IsParallelSafe:
Das eine heisst "stoert keinen gleichzeitigen Aufruf", das andere
"richtet zweimal keinen Schaden an". CrashRecovery sichtet beim Start,
was offen blieb, und stuft ein - fuehrt aber nichts aus. Es sichtet und
berichtet; entscheiden soll der Aufrufer.
Dabei kippte eine alte Regel: Bisher wurde ein Abbruch bewusst NICHT
protokolliert. Das war richtig, solange es keinen Eintrag vor dem Aufruf
gab. Jetzt saehe sonst jeder Benutzerabbruch beim naechsten Start aus wie
ein Absturz - bis niemand mehr hinsieht. Deshalb AuditStatus.Cancelled.
#555 Optionale Zustandspruefung IToolStateProbe, umgesetzt in FileRW.
Unknown ist eine vollwertige Antwort, kein Fehlschlag: Ob ein SMTP-Server
angenommen hat, laesst sich nicht feststellen, und ein Werkzeug, das hier
raet, waere schlimmer als eines, das schweigt. Partial gilt ausdruecklich
nicht als geklaert - einen halb angehaengten Text sollte niemand
automatisch geraderuecken.
#556 Auswertung. ListForAgentAsync und SummarizeToolUsageAsync. Die Dauer
wird nur ueber abgeschlossene Aufrufe gemittelt; zaehlten die
Started-Eintraege mit ihrer Dauer 0 mit, saehe jedes Werkzeug doppelt so
schnell aus, wie es ist.
Nebenbei: SqliteStorage kann jetzt Spalten nachruesten. CREATE TABLE IF
NOT EXISTS allein genuegte nicht - bei einer bestehenden Datenbank tut die
Anweisung nichts, und erst das naechste INSERT waere gescheitert, im
Betrieb beim Anwender.
Vier Audit-Tests angepasst: Ein ausgefuehrter Aufruf erzeugt jetzt zwei
Eintraege statt einem. Ein Aufruf, der gar nicht erst laeuft - verweigert,
unbekannt, vorgelegt - hat weiterhin genau einen; der Beginn wird erst
nach Rechtepruefung und Staging geschrieben.
23 neue Tests, 912 gesamt, keine Regression. Build ohne Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wurde ein Chat abgebrochen, waehrend ein Werkzeug lief, blieb im Kontext
eine assistant-Nachricht mit tool_calls stehen, auf die keine Antwort
folgte. Diese Folge lehnt die Schnittstelle mit HTTP 400 ab - der Agent
war danach nicht mehr ansprechbar.
Der Schaden wurde dabei dauerhaft gemacht: Jeder catch-Block ruft
AddChatEntry, das ruft PersistChatState, und das schreibt den Kontext
atomar auf die Platte. Das atomare Schreiben war hier keine Rettung,
sondern die Garantie, dass die kaputte Fassung heil ankommt. Ein Neustart
half nicht, weil LoadPersistedChats sie zurueckholte.
Ausloeser war durchweg Normalbetrieb: AbortChat durch den Benutzer,
LoopGuard.Timeout, oder eine Instanz, die waehrend eines Werkzeuglaufs
geordnet herunterfaehrt.
Die Antworten gehen jetzt aus einem finally raus. Auf jedem Ausgangspfad
bekommt jeder Aufruf seine Antwort, bei Abbruch eine Ersatzantwort, die
auch sagt, was passiert ist - eine leere waere formal gueltig, liesse das
Modell aber raetseln.
Zwei Tests: einer auf die Form des Kontexts, einer auf das, worauf es
ankommt - dass ein zweiter Chat danach wieder durchlaeuft. Der erste
schlug vor der Behebung fehl.
543 Tests in Core, keine Regression. Build ohne Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fuenf Befunde mit einem gemeinsamen Fehlermodus: Keiner erzeugt eine
Fehlermeldung. Der Lauf wird fertig, das Ergebnis sieht plausibel aus,
und nur die Qualitaet ist schlechter.
#547 Der Begleittext zum Werkzeugaufruf ging verloren. AssistantWithToolCalls
baute eine neue Nachricht aus nur den Aufrufen; der Text, den das Modell
daneben geschrieben hatte, fiel weg. Damit verlor das Modell zwischen zwei
Schritten seinen eigenen Plan, und im Audit stand, dass ein Werkzeug lief,
nicht warum.
#548 finish_reason wurde nirgends gelesen. Eine an der Ausgabegrenze
abgeschnittene Antwort galt als fertiges Ergebnis. Das trifft besonders
Laeufe im Hintergrund, wo niemand zusieht. Neuer Status Truncated: Das
Teilergebnis geht weiter, aber gekennzeichnet.
#549 reasoning_details wurde verworfen. Bei Werkzeugnutzung muss der
Denkverlauf unveraendert zurueck, sonst beginnt ein Thinking-Modell jedes
Mal von vorn. Wird jetzt als rohes JSON durchgereicht - ohne Auslegung,
weil Reihenfolge und Signatur daran haengen.
#550 Die Anfrage verlangt jetzt einen Anbieter, der alle mitgeschickten
Parameter beherrscht. Ohne das durfte ein Anbieter cache_control, reasoning
oder sogar tools stillschweigend uebergehen - der Lauf lieferte dann eine
gewoehnliche Textantwort, wo ein Werkzeugaufruf hingehoert haette. Dazu
usage.include: der abgerechnete Betrag schlaegt die Eigenrechnung, die als
Rueckfallebene bleibt. Denktiefe je Agent einstellbar, Vorgabe off.
#551 Werkzeuge eines Zuges laufen gleichzeitig, sofern sie sich dafuer
freigeben. Die Vorgabe von IsParallelSafe ist false, weil die falsche
Antwort hier nicht auffaellt: Zwei schreibende Aufrufe auf derselben Datei
scheitern nicht zuverlaessig, sondern gelegentlich. Freigegeben ist bisher
nur WebFetch - es liest ausschliesslich. Die Reihenfolge der Ergebnisse
folgt den Aufrufen, nicht der Fertigstellung; daran haengen die
tool_call_id-Zuordnung und der Cache-Praefix.
27 neue Tests, 887 gesamt, keine Regression. Build ohne Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eine Sicherung des Managers ist jetzt als Ganzes mit dem Lizenzschluessel
verschluesselt. Beim Zurueckspielen wird der eigene Schluessel probiert; passt er
nicht, fragt die Oberflaeche nach dem Lizenzschluessel der Quellinstallation.
Der Lizenzschluessel ist der eine Wert, den jede Installation ohnehin hat, und er
liegt im Manager, nicht neben den Archiven. Damit faellt der Grund weg, aus dem die
taegliche Sicherung bisher keine Zugangsdaten enthielt: Eine Passphrase haette
gespeichert werden muessen, und neben den Sicherungen waere sie wirkungslos
gewesen. Jetzt reisen die Zugangsdaten mit, und eine Sicherung uebersteht den
Maschinenwechsel ohne Passphrase.
LicenseBackupCipher: eigener Behaelter .clawdbak. Kopf mit Schluesselprobe, das
Manifest als eigener Abschnitt, das ZIP in 1-MiB-Stuecken mit AES-256-GCM und
Endmarke. PBKDF2 aus Lizenzschluessel und festem Salt, der Schluessel normiert.
Kein RAR (braucht das lizenzpflichtige Herstellerprogramm), kein ZIP mit Kennwort
(kann .NET nicht schreiben, ZipCrypto ist gebrochen, und mit abgeleitetem
Schluessel braechte 7-Zip-Vertraeglichkeit nichts).
Zurueckspielen: Die Schluesselprobe laeuft VOR dem Anhalten der Instanz. Passt
der Schluessel nicht, antwortet der Endpunkt mit 422 und dem Code fremde_lizenz,
und ein Fenster verlangt den Schluessel der Quelle.
ManagerBackups: Gefuehrte Instanzen sichern sich nicht mehr selbst, weil nur der
Manager den Schluessel hat; er liest ihre Einstellungen aus InstanceSettings.json.
Einmal am Tag auch ueber einen Neustart des Managers hinweg. Ohne Lizenzschluessel
wird nichts gesichert, auch nicht ersatzweise unverschluesselt.
FTP (FluentFTP, schon im Loesungsbaum): TLS wo angeboten, requireTls erzwingt es;
Upload unter .part-Namen und danach umbenannt; Aufraeumen auf dem Server je
Instanz; ein gescheiterter Upload laesst die lokale Sicherung stehen. Das
Kennwort liegt verschluesselt in manager.json und geht nie an die Oberflaeche.
Welche Datei zu welcher Instanz gehoert, entscheidet ein Zeitstempel nach dem
Namen und nicht das Praefix - Test und Test_2 werden nicht mehr verwechselt.
Grenze, bewusst und dokumentiert (Konzept 9.10): Wer Lizenzschluessel und Archiv
hat, hat die Zugangsdaten. Der Schluessel ist dem Hersteller bekannt und gilt fuer
alle Instanzen einer Installation.
Nicht ueber die Oberflaeche abgenommen: Fenster fuer die fremde Lizenz und FTP
gegen einen echten Server stehen als Block H in #537.
860 Tests gruen, 0 Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SecretKeyStore.Wrap band den Hauptschluessel unter Windows per DPAPI ans
Benutzerkonto und gab ihn sonst ungewrappt zurueck - eine Zeile, die man beim
Lesen ueberspringt und die auf dem Zielsystem "im Klartext" bedeutet.
Dahinter steht jetzt ein SecretKeyRing: derselbe Hauptschluessel, mehrfach
verpackt, je Fach ein ISecretProvider (dpapi, passphrase, file). Fuer Aufrufer
aendert sich nichts - GetOrCreateKey gibt weiterhin 32 Byte zurueck. Genau dafuer
war die Naht da.
WARUM MEHRERE FAECHER UND NICHT EIN BESSERES
Ein Schluessel an der Maschine ueberlebt keinen Umzug; einer an einer Passphrase
verlangt bei jedem Start jemanden, der tippt - und Dauerbetrieb ohne Menschen ist
der Zweck (#214). Der Bund entscheidet sich nicht: Im Alltag oeffnet das
Maschinenfach ohne Rueckfrage, nach einem Umzug die Passphrase, und beide fuehren
zu DEMSELBEN Schluessel. Alle enc:v2-Werte bleiben lesbar.
Und deshalb darf die Schluesseldatei jetzt ueberhaupt in eine Sicherung: Sobald
ein Wiederherstellungsfach da ist, steht der Hauptschluessel in keiner Fassung im
Klartext darin.
Nicht zu verwechseln mit der Sicherung mit Passphrase: Die schluesselt jeden WERT
einzeln ins Archiv um, fuer den Transport einer Instanz. Das Wiederherstellungs-
fach schluesselt den HAUPTSCHLUESSEL um, damit eine bestehende Installation
weiterlaeuft - unbeaufsichtigt ueber CLAWD_SECRET_PASSPHRASE. Die Unterscheidung
steht in docs/Roadmap.md bei #190.
Beide Altformate werden uebernommen: 32 rohe Byte werden zum Fach file, ein
DPAPI-Block zum Fach dpapi. Derselbe Schluessel, nur anders verpackt.
Zwei Zusagen, mit Tests festgehalten:
- Geht KEIN Fach auf, wird abgebrochen statt ein neuer Schluessel erzeugt. Ein
neuer Hauptschluessel machte jeden bestehenden Wert wortlos unlesbar.
- Ein Umzug legt den Schluessel NICHT im Klartext ab, nur damit der naechste Start
bequemer wird.
Beim automatischen Weg wird nur hinzugefuegt, nie weggenommen; weggenommen wird
nur in SetRecoveryPassphrase, wo ein Mensch gerade getippt hat.
#190 bleibt offen: Unter Linux greift weiterhin das Fach file. Neu ist, dass es
beim Start als Warnung im Protokoll steht statt unsichtbar zu sein. Womit das
Maschinenfach dort gefuellt wird, ist Entscheidung #180 - diese Schnittstelle ist
die Stelle, an der die Antwort eingesetzt wird.
834 Tests gruen, 0 Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mit E-M3 wanderte die Lizenzpruefung in den Manager: Eine gefuehrte Instanz prueft
nicht mehr selbst, weil der Manager es zentral getan hat. Woran sie "gefuehrt"
erkannte, war der Schalter --managed - und ein Schalter ist keine Erkennung.
ClawdDotNet --managed startete damit eine Instanz ganz ohne Lizenzpruefung. Vor
E-M3 gab es die Luecke nicht; sie ist mit der Zentralisierung entstanden.
ManagerHandshake unterschreibt Instanzverzeichnis und Ablauf mit HMAC-SHA256. An
die Signierstelle kommt der Manager nur, wenn seine Lizenzpruefung bestanden hat -
StartInstanceAsync weist vorher mit StartRefusal.NoLicense ab. Dass die
Unterschrift existiert, ist der Beweis.
- Gebunden an das Verzeichnis, und geprueft wird gegen das tatsaechliche, nicht
gegen das behauptete: Sonst unterschriebe man das Argument statt der Sache.
- Fuenf Minuten gueltig, der Ablauf geht in die Unterschrift ein.
- Ueber die Umgebung statt ueber die Befehlszeile: Eine Befehlszeile steht in
jeder Prozessliste.
- Ungueltig heisst "nicht gefuehrt", nicht Abbruch. Dann prueft die Instanz ihre
Lizenz selbst - der Weg von vor E-M3, also kein neuer Fehlerfall.
AppHost.IsManaged ist jetzt der gepruefte Befund. CanSwitchInstance und der
Wechseldialog haengen daran statt am Schalter.
Die Grenze steht ausdruecklich im Konzept (9.9): Der Schluessel liegt in jeder
ausgelieferten Programmdatei. Es geht um den gewoehnlichen Weg an der Lizenz
vorbei, nicht um jemanden mit Werkzeugen und Willen.
Abgenommen an echten Prozessen, Unterschrift fuer den Positivfall unabhaengig in
Python gerechnet: ohne Unterschrift "Lizenz erforderlich"; mit gueltiger kommt die
Instanz hoch; Unterschrift fuer ein fremdes Verzeichnis und hochgedrehter Ablauf
scheitern beide.
820 Tests gruen, 0 Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Weboberflaeche (#531): X-Instanz an der einen fetch-Stelle, Instanzauswahl in der
Kopfzeile, Verwaltungsansicht mit Anlegen/Starten/Anhalten/Fenster, Herkunft der
Ereignisse, Sicherungs- und Einstellungsansicht. 402/409/502 werden eigen behandelt.
Sicherungen im Manager (#530): Auflisten, Anlegen, Wiederherstellen, Loeschen. Das
Zurueckspielen haelt die Instanz vorher an und startet sie danach wieder.
Geordnetes Ende (Konzept 9.8). Zwei Befunde waren der Anlass:
Der Manager konnte eine Instanz MIT FENSTER nie geordnet beenden.
Control.ShutdownRequested war nur in HeadlessRun verdrahtet, nicht in der
Avalonia-Anwendung - und ein Fenster ist die Vorgabe. Die Bitte wurde mit 202
beantwortet, niemand hoerte zu, und der Manager schoss den Prozess nach Ablauf
seiner Frist jedes Mal ab.
InstanceSupervisor.StopAsync hielt Socket-Schweigen fuer einen Todesnachweis und
meldete "beendet", ohne den Prozess anzufassen. Bei einer verstummten Instanz ist
der Socket von vornherein still - der Neustart haette einen zweiten Prozess auf
dieselbe state.db gesetzt. Genau der Schaden, gegen den #528 gebaut ist.
- ShutdownCoordinator: erst die Tuer schliessen, dann auf offene Arbeiten warten,
Frist zwei Minuten. Vorher brach TaskScanner.DisposeAsync mitten in ProcessAsync
ab, sodass die Aufgabe bis zum Lease-Ablauf auf "running" stehenblieb.
- GET /api/instanz/puls hinter dem Socket-Gate: Phase und offene Arbeiten. Weiter
gefragt statt gemeldet - ein Puls, den die Instanz von sich aus schickt, fehlt
genau dann, wenn sie haengt.
- Eskalationsleiter: drei Durchgaenge ohne Antwort, einmal um ein Ende bitten,
nach 30s beenden und den Vollzug abwarten, gemeldet als Absturz.
- EnsureDeadAsync vor jedem Start.
Weiteres aus dem Review:
- .gitignore verankert: "Instances/" passte auch auf src/ClawdDotNet.Core/Instances/.
InstanceEndpoint.cs und InstanceLayout.cs waren dadurch nie eingecheckt.
- Das WebUI-Token stand im Protokoll des Managers. Konsole ja, Datei nein.
- Ein Klick auf "Instanz anlegen" loeste requestSubmit() zweimal aus.
- [Obsolete] auf WebServerPort wieder entfernt: sechs Warnungen, die niemand
abstellen konnte, solange E-M5 nicht fertig ist.
- Die Wiederherstellung bricht nicht mehr ab, wenn der Browser weggeht.
- Entwicklungspfade zum Instanzmanager aus Segmenten statt mit Rueckstrichen, und
der Port kommt aus manager.json statt fest aus der Zeile.
Offen und gemeldet: --managed hebelt die Lizenzpruefung aus (#535).
806 Tests gruen, 0 Warnungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der C#-Teil des Instanzmanagers ist fertig; was fehlt, ist die
Oberflaeche. Abschnitt 11 im Konzeptpapier ist die Uebergabe dafuer: der
Auftrag in einem Satz, die harte Grenze (keine .cs-Datei, git status darf
nur wwwroot zeigen), die vollstaendige API mit den Antwortcodes, die eine
eigene Behandlung verdienen, eine Reihenfolge, zwei Fallen und die drei
Punkte, die ausdruecklich liegen bleiben, weil sie C# sind.
Der WebUI-Leitfaden war an vier Stellen ueberholt und haette den naechsten
Agenten in die Irre geschickt: wwwroot liegt nicht mehr in
ClawdDotNet.Web, die Oberflaeche laeuft nicht mehr im Prozess der Instanz,
Port und Token stehen in manager.json statt in InstanceSettings.json, und
es gibt nicht mehr ein /api fuer eine Instanz. Ein Korrekturblock steht
jetzt vorweg und verweist auf Abschnitt 11; der Rest des Leitfadens - kein
innerHTML, kein Paketmanager, Token nur im sessionStorage, Farben aus
app.css - gilt unveraendert.
Die Arbeit selbst ist #531 und steht auf der Roadmap. Was nur in einer
Datei steht, ist keine eingeplante Arbeit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entschieden vom Benutzer am 2026-09-08. Der Schalter heisst
autostartByManager und steht in InstanceSettings.json - bei der Instanz,
nicht beim Manager.
ZWEI DINGE IN EINEM SCHALTER, weil es dieselbe Zusage ist: Der Manager
startet diese Instanz, wenn er selbst hochkommt, und er startet sie wieder,
wenn sie abstuerzt. Ohne den Schalter ruehrt er nichts an - ein Manager,
der nach einem Neustart der Maschine alles hochfaehrt, was er findet,
startet auch das, was jemand mit Absicht angehalten hat. Ausgeschaltet
vorbelegt.
DER SICHERUNGSAUTOMAT ist der eigentliche Inhalt. Wieder hochzufahren ist
die einfache Haelfte; die schwierige ist zu erkennen, wann man es lassen
muss. Nach drei Neustarts in zehn Minuten (maxRestartsInWindow,
restartWindowMinutes) setzt der Manager aus und meldet es. Die Instanz
bleibt dann aus, bis jemand sie von Hand startet - und dieser Start raeumt
den Zaehler ab, denn wer von Hand startet, hat entweder etwas geaendert
oder weiss, was er tut. Das Zeitfenster wandert: Eine Instanz, die einmal
im Monat abstuerzt und wieder hochkommt, laeuft nie in die Grenze.
Nur bei einem Absturz, nicht wenn eine Instanz verstummt. Eine stumme
Instanz lebt noch; sie neu zu starten hiesse, sie erst abzuschiessen, und
ob der Manager das von sich aus darf, ist nicht entschieden. Als offene
Frage aufgeschrieben - genau dieser Zustand war der Anlass des Vorhabens.
Der Schalter steht bei der Instanz, weil er eine Eigenschaft dieser Instanz
ist und weil die Instanzdatei dem Instanzprozess gehoert: Sie vom Manager
schreiben zu lassen, waehrend die Instanz laeuft, waeren zwei Schreiber auf
einer Datei. Der Manager liest ihn nur; geaendert wird er auf der
Einstellungsseite der Instanz.
EIN DEFEKT, den erst diese Tests gezeigt haben: StartAsync gab "laeuft
schon" zurueck, wenn die Aufsicht die Instanz fuer laufend hielt - ohne
nachzusehen. Zwischen zwei Aufsichtsdurchgaengen liegen aber Sekunden, und
in denen kann sie wegbrechen. Wer in dieser Luecke "starten" verlangte,
bekam einen Erfolg, hinter dem nichts stand, und der naechste Durchgang
meldete einen Absturz, den niemand mehr erwartete. Jetzt wird gefragt,
bevor zugestimmt wird.
UND EIN TESTDOUBLE, das die Wirklichkeit nicht abbildete: Der falsche
Socket antwortete unabhaengig davon, ob ein Prozess lief. Damit war jeder
Testaufbau, der die Antwort vor dem Hochfahren hinterlegte, stillschweigend
ein anderer Test als beabsichtigt - eine Antwort sagt dem Manager "laeuft
bereits", er uebernimmt, und der Starter wird nie angefasst. Dreimal
passiert. Der falsche Socket haengt jetzt am falschen Starter.
Sicherungen im Manager sind als #530 zurueckgestellt, mit Ausloeser.
Vorab entschieden ist dort nur eines: Zurueckspielen ausschliesslich bei
inaktiver Instanz.
19 neue Tests. Build ohne Warnungen, 793 Tests gruen, 8 uebersprungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vorher hiess "Instanz wechseln": Der laufende Prozess faehrt sich herunter
und startet sich mit einer anderen Instanz neu. Wer wechselte, beendete
zwangslaeufig die Instanz, aus der heraus er es tat - und genau dabei hat
sich die Anwendung am 2026-09-08 aufgehaengt (#529). Jetzt laufen alle, und
es kommt eine nach vorn.
Neu: POST /api/instanz/fenster, wieder ausschliesslich ueber den Socket.
Die Instanz holt ihr Fenster SELBST nach vorn; der Manager kennt kein
Fenstersystem und soll keines kennen. Kopflos laeuft die Bitte ins Leere,
und das ist die richtige Antwort. Das letzte Wort hat der Fenstermanager -
Windows laesst einen Hintergrundprozess den Vordergrund nicht einfach an
sich reissen; der kurze Ausflug ueber Topmost half im Versuch, unter Linux
entscheidet der Fenstermanager. Mehr als bitten kann eine Anwendung nicht.
ShutdownSignal ist zu InstanceControl geworden: beenden und Fenster sind
zwei Bitten desselben Absenders ueber denselben Weg. Beenden gilt einmal,
das Fenster beliebig oft - jeder Wechsel auf diese Instanz ist einer.
--managed schaltet den Wechsel im Instanzfenster ab. Der Manager gibt es
jedem Instanzprozess mit; das Fenster graut seinen Instanz-Schalter aus und
erklaert auf Nachfrage, wo gewechselt wird. Zwei Schloesser an derselben
Tuer: Der Knopf ist aus, und der Weg dahinter prueft es noch einmal - denn
hinter ihm wartet ein Selbst-Neustart.
instanceWindows in manager.json, vorbelegt auf true: Jede Instanz behaelt
ihr Fenster. Auf einer Maschine ohne Bildschirmsitzung gehoert false hin.
ABNAHME an echten Fenstern: Instanz ueber den Manager gestartet, PID 18128,
Fenstertitel "ClawdDotNet", Befehlszeile mit --managed. Fenster von aussen
minimiert (IsIconic True), dann POST /instanzen/Instance-Test/fenster:
IsIconic False, im Vordergrund - und PID unveraendert 18128. Nichts neu
gestartet. Das ist die Abnahmebedingung dieser Stufe.
Build ohne Warnungen, 780 Tests gruen, 8 uebersprungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
