- CancelKeyPress-Event registrieren → .Cancel() → ReceiveAsync bricht sauber ab
- catch [AggregateException] für CancellationToken in .GetAwaiter().GetResult()
- Event-Handler im finally-Block entfernen
- /remote als Alias für /remote.ps1
- RemoteConnectionManager: Singleton-Service verwaltet WebSocket-Verbindungen
mit Command-Execution (Send/Receive mit Timeout + SemaphoreSlim-Locking)
- RemoteEndpoint: WebSocket-Endpoint /api/remote (auth-frei), REST-APIs für
Connections/Assign/Unassign, PowerShell-Script-Auslieferung mit dynamischer URL
- remote.ps1: PowerShell-Client für Windows – verbindet per WebSocket,
sendet Hostname/User/OS, empfängt und führt Befehle aus, Heartbeat
- remote_execute Tool: Neues Agent-Tool, nur verfügbar wenn Session eine
zugeordnete Remote-Verbindung hat, führt PowerShell-Befehle remote aus
- Frontend: Menüpunkt 'Remote-Verbindungen' im Chat-Dropdown, Modal zeigt
alle aktiven WebSocket-Verbindungen (Hostname, User, OS, Verbindungszeit),
Verbinden/Trennen-Buttons pro Verbindung und Session
- Auth: /api/remote und /remote.ps1 von Authentifizierung ausgenommen
Architektur: Windows-Client → WebSocket → GOTT-Server → Agent-Tool
Session-gebunden: Eine Verbindung wird einer Session zugeordnet
Bug: Nach ask_user_choice wurde die vorherige Chain (mit allen tool_use/
tool_result Paaren) nur als Text geladen statt vollständig. Die API bekam
tool_use IDs ohne zugehörige tool_result Blöcke → 400 Error.
Ursache: Die fullChainStartIndex-Logik prüfte nur ob die AKTUELLE Chain
eine tool_result mit Iteration 999 hat. Aber die Choice-Antwort wird in
die VORHERIGE Chain gespeichert (ChatEndpoint Zeile 68-78), nicht in die
aktuelle. Deshalb wurde needsPrevious=false → vorherige Chain nur als Text.
Fix: Dritte Prüfung hinzugefügt - wenn die vorherige Chain mit
stop_reason='awaiting_user_choice' endete, muss sie vollständig geladen
werden (sie enthält den tool_use UND den tool_result für die Choice).
- Bei API 400 'prompt is too long' / 'exceed context limit':
- 20% der ältesten Messages aus In-Memory-History entfernen
- TrimMessagesCleanly() verhindert Trennung von tool_use/tool_result-Paaren
- Retry mit kürzerer History (max 5 Retries im Worker)
- Alle 3 API-Call-Stellen abgesichert (StreamChat, RunAgentChat, ChatNonStreaming)
- Frontend: Neues 'info'-Event als Warning-Bubble angezeigt
- MaxHistory 220 bleibt als Obergrenze, dynamische Kürzung bei Token-Überschreitung
Vorher wurden nur orphaned server_tool_use entfernt (die keinen
web_search_tool_result hatten). Jetzt auch umgekehrt: web_search_tool_result
Blöcke ohne zugehörigen server_tool_use werden entfernt.
Mögliche Ursache für API 400 'web_search_tool_result without corresponding
server_tool_use': Parse-Fehler beim Laden des server_tool_use aus der DB
oder Reihenfolgeprobleme führten dazu, dass nur der Result-Block in der
History landete.
Problem: API 400 'web_search tool use without corresponding
web_search_tool_result block' – weil web_search_tool_result nur als
Sources-Array gespeichert wurde und in BuildHistoryFromDb kein Handler
dafür existierte. Der server_tool_use-Block war in der History, aber
der zugehörige web_search_tool_result fehlte.
Backend (AnthropicService):
- 3 Speicher-Stellen (StreamChat, RunAgentChat, ChatNonStreaming):
Raw-JSON statt ExtractWebSearchSources-Array speichern
Backend (ChatService):
- Neuer Handler für web_search_result in BuildHistoryFromDb:
Raw-JSON als web_search_tool_result in assistant content einfügen
- Rückwärtskompatibilität: Alte Array-Einträge überspringen
- CleanOrphanedWebSearchBlocks(): Post-Processing entfernt
orphaned server_tool_use mit name web_search (alte DB-Einträge)
Frontend (history.js, shared-page.js):
- _extractWebSearchSources(): Unterstützt altes Array-Format und
neues Raw-JSON Format (content[].type === web_search_result)
Ursache: WriteSseEvent in ProcessStream warf OperationCanceledException
bei Client-Disconnect (Page-Refresh) → sseCt war gelinkt mit dem
ASP.NET cancellationToken → Exception wurde im catch-Block als
'stopped' behandelt → Agent brach ab obwohl nur der Browser refreshed wurde.
Fixes:
- ProcessStream: Alle WriteSseEvent durch TryWriteSse ersetzt
SSE-Writes bei Client-Disconnect werden jetzt zu stillen No-Ops
statt den gesamten Agent-Flow per Exception zu killen
- catch-Blöcke: OperationCanceledException nur bei workCt/hardCt als
'stopped' behandeln, neuer catch für Client-Disconnect als
'client_disconnected' (Fallback, sollte nicht mehr auftreten)
- done-Event nach Stop: sseCt → CancellationToken.None damit das
done-Event trotz gecancelltem sseCt noch gesendet wird
- Frontend: done-Handler rendert Chain-Badge direkt im apiGetChain-
Callback statt Race-Condition mit finally-Block
- Frontend: 'stopped' Badge wieder angezeigt (war nur fälschlich bei
Page-Refresh, jetzt korrekt nur bei echtem Stop)
Stop-Button: Zwei Stufen statt einer:
- 1. Klick: Graceful Stop (workCt) - laufende API-Calls/Tools abbrechen
- 2. Klick: Hard Stop (hardCt) - sofortiger Abbruch aus while-Loop
StreamingTracker: Zwei separate CancellationTokenSources (StopCts + HardCts),
Cancel() gibt 'graceful'/'hard'/null zurück je nach Stufe.
ReadLineAsync Cancellation-Fix: StreamReader.ReadLineAsync propagiert den
CancellationToken nicht zuverlässig an den underlying NetworkStream.
Bei extended thinking blockiert ReadLineAsync minutenlang ohne Reaktion
auf Cancellation. Fix: workCt.Register() disposed den HTTP-Stream,
damit ReadLineAsync sofort mit Exception abbricht.
Bug-Fix: OperationCanceledException in RunAgentChat/ChatNonStreaming wurde
vom generischen catch(Exception) geschluckt - Agent lief trotz Stop weiter.
Jetzt: catch(OperationCanceledException) { throw; } vor catch(Exception).
Frontend: Stop-Button zeigt Hard-Stop visuell (rot + Pulse-Animation),
SSE-Stream wird erst beim 2. Klick clientseitig abgebrochen.
- Kestrel MinResponseDataRate per-Request deaktivieren für SSE-Streams
(Default 240 bytes/s + 5s Grace → client_disconnected bei langen Tools)
- SSE-Heartbeat alle 15s während Stream (schützt gegen Browser/Netzwerk-Idle)
- History-Trimming: RemoveRange schneidet nicht mehr in tool_use/tool_result-Paare
- Reminder-Insertion: kein Einfügen zwischen tool_use und tool_result
tool_use case setzt jetzt dataset.toolName auf das DOM-Element.
tool_result case erkennt todo_write und ruft buildTodoList() auf
statt ein hidden text-div anzuhängen.
Bug: Bei 2+ aufeinanderfolgenden ask_user_choice-Runden wurden ältere
Choice-Chains nur als Text geladen. Claude sah die früheren tool_use/
tool_result-Paare nicht → kein Kontext über bereits beantwortete Fragen
→ Agent stellte dieselben Fragen erneut (Dauerschleife).
Fix: fullChainStartIndex-Logik traversiert jetzt rückwärts durch alle
zusammenhängenden Choice-Chains (erkannt an tool_result mit Iteration 999).
Alle werden vollständig geladen, damit die gesamte Frage-Antwort-Historie
für Claude sichtbar bleibt.
Backend: sb.AppendLine() durch sb.Append()+\n ersetzt für
konsistente Zeilenenden auf allen Plattformen.
Frontend: \r defensiv entfernen vor Regex-Matching, da
JS-Regex (.+)$ kein \r matcht und nur letzte Zeile geparsed wurde.
- HttpResponseMessage mit using disposen (3 Stellen in AnthropicService)
verhindert Socket-Exhaustion unter Windows (2 Connections/Host Limit)
- SSE DisableBuffering() in ChatEndpoint für sofortigen Flush unter Windows
- Execute: stdout/stderr vor WaitForExitAsync lesen statt danach
verhindert Pipe-Deadlock bei vollem Buffer (Windows: 4KB)
- Plan-Modus: Frontend sendet planMode bei Choice-Response mit
Backend-Fallback auf vorherigen Chain entfernt - User-Entscheidung gilt
Plattformspezifische bin/obj/publish-Ordner unter Build/Linux/
und Build/Windows/ statt bin-linux/, obj-linux/, publish/ etc.
- Directory.Build.props: OS-Erkennung setzt BaseOutputPath,
BaseIntermediateOutputPath und MSBuildProjectExtensionsPath
auf Build/{Linux|Windows|macOS}/
- gott.csproj: Vereinfacht auf ein einziges Build/** Exclude
- deploy.sh: publish-Output nach Build/Linux/publish
- OpenClawEndpoint.cs: DB-Pfad relativ zu AppContext.BaseDirectory
- Doku (README, ARCHITECTURE, ARCHITECTURE_QUICK) aktualisiert
_mergeConsecutiveAssistantTexts aktualisierte beim Zusammenführen
aufeinanderfolgender Assistant-Text-Messages die id und createdAt,
aber nicht den sortKey. Dadurch blieb lastKnownMessageId auf dem
niedrigeren sortKey der ersten Message stehen.
Folge: Beim nächsten Poll wurden bereits geladene Messages erneut
geliefert (afterSortKey zu niedrig) → Duplikate im Chat.
lastKnownMessageId wurde pro Poll nur um 1 erhöht statt auf den
tatsächlich höchsten Wert.
- server_tool_use-Blöcke werden jetzt in DB persistiert und in
History-Rekonstruktion als Raw-JSON eingefügt
- Generische *_tool_result-Behandlung (bash_code_execution_tool_result,
code_execution_tool_result etc.) in allen drei Chat-Pfaden:
StreamChat, ChatNonStreaming, RunAgentChat
- ProcessStream: serverToolResultBlocks analog zu webSearchResultBlocks
- BuildHistoryFromDb: server_tool_use + server_tool_result werden
korrekt in Assistant-Content-Array rekonstruiert
- Behebt API 400: tool_use without corresponding tool_result
- Neuer Abschnitt 'Was NICHT ins Memory gehört' im System-Prompt
- Klarstellung: Memory ist agent-übergreifend (über alle Sessions geteilt)
- Keine Session-Kontexte/System-Prompt-Inhalte ins Memory kopieren
- Nur langfristig relevante Infos speichern (Präferenzen, Konventionen)
- tool_end SSE-Event: 500-Zeichen-Limit entfernt (2 Stellen), damit
todo_write und andere Tools beim Streaming vollständig angezeigt werden
- BuildHistoryFromDb: TruncateToolResult (20k) auf tool_result-Messages
angewendet, um Token-Overflow bei History-Rebuild zu verhindern
(609k Tokens > 200k Limit nach awaiting_user_choice)
- TruncateToolResult/MaxToolResultChars auf internal geändert
- TODO.md: todo_write-Bug als erledigt markiert
- MaxHistory (Default: 120): Max History-Messages pro API-Request
- ReminderInterval (Default: 30): System-Prompt Reminder alle N Messages (0 = deaktiviert)
- Beide Werte über Server-Settings-UI konfigurierbar
- Hardcoded Werte in ChatService durch konfigurierbare Felder ersetzt
- Telegram-Bot-Page: Webhook-Secret und Webhook-Section immer sichtbar (hidden-Logik entfernt)
- Agent-Page: Public-Checkbox in scrollbaren Bereich verschoben, Sichtbarkeit-Label hinzugefügt
- Konsistente Bezeichnung: Public → Öffentlich mit Hint-Text
- Session-Page: Redundantes Telegram-Label entfernt
- Telegram-Bots-Überschrift: Icon entfernt (konsistent mit anderen Sektionen)
Problem: systemd setzt WorkingDirectory=/app/gott (= ContentRoot),
aber AppContext.BaseDirectory zeigt auf /app/gott/publish/.
Dadurch existierten zwei appsettings.Production.json – .NET las die
eine, die Server-Settings-UI schrieb die andere. Config-Änderungen
wie PayloadLogging hatten daher keinen Effekt.
Fix: ProductionConfigPath und FallbackConfigPath werden jetzt von
app.Environment.ContentRootPath abgeleitet statt AppContext.BaseDirectory.
- SystemPromptBuilder.BuildReminder(): generiert automatisch Reminder-Text
aus den aktiven Prompt-Blöcken (Identity, Workspace, Memory, etc.)
- Alle ~30 Messages wird ein [System Reminder]-Paar in die History injiziert
(nur nach assistant-Messages, um user/assistant-Alternierung zu wahren)
- History auf maximal 120 Messages begrenzt (älteste werden entfernt)
- ChatContext um PromptBlocks-Property erweitert
- Alle Aufrufer (ChatEndpoint, TelegramService, CronjobService) übergeben
promptBlocks an BuildHistoryFromDb
- Remove tool_choice from AgentEndpoint (create, update, list responses)
- ChatService: automatically set tool_choice='any' when workspace, memory
or skills present, null otherwise. Same for preparer/review/finalizer
- SystemPromptBuilder: remove 3 toolAny-conditional prompt blocks
(KRITISCH, Verhalten, ERINNERUNG)
- Frontend: remove checkbox, badge and JS references
- Agent.ToolChoice DB field preserved for backward compat, no longer read
Wenn eine Telegram-Nachricht von einem nicht verknüpften Chat eingeht:
- Sucht nach Sessions mit diesem Bot, die noch keine Chat-ID haben
- Genau 1 unverknüpfte Session → automatisch zuweisen + Bestätigung
- 0 oder mehrere → Chat-ID anzeigen, manuell im Web-UI zuweisen
Neue DB-Methode: FindUnlinkedSessionsForBot(botId)
Der Tag-Filter in BuildHistoryFromDb filterte alle Messages mit Tag
aus, sofern der Tag nicht dem angeforderten includeTag entsprach.
openclaw-import ist jedoch kein Sub-Agent-Tag (wie preparer/review/
finalizer), sondern ein Herkunfts-Tag und muss immer in der History
enthalten sein.
- AgentRecord: neues IsPublic-Feld mit DB-Migration
- GET /api/agents/available: eigene + public Agents (alle Properties + isOwner)
- GET /api/telegram/bots/available: alle Properties außer Token/Secret + sessionCount
- Agent-Page: Public-Checkbox (andere User können Agent in Sessions verwenden)
- Dashboard: agentMap aus availableAgents gebaut (public Agents fremder User auflösbar)
- Session-Page + Cronjob-Page: Agent-Picker nutzt /available statt /agents
- Agent-Cards: Public- und Fremd-Badges
- Fix: Chat-Button bei Sessions mit public Agent eines anderen Users nicht mehr disabled
Backend:
- New OpenClawEndpoint with GET /api/openclaw/sessions and POST /api/openclaw/import
- Lists all OpenClaw sessions with preview messages, model, summary
- Imports user/assistant text messages (skips tool-use/tool-result)
- Cleans user messages (removes webchat prefixes, cron tags, conversation info blocks)
- Re-import support: deletes previous openclaw-import chains before importing
- New DatabaseService methods: CreateChainForImport, CreateMessageForImport, DeleteOpenClawImport
- Added SortKey to MessageRecord (computed: openclaw-import gets id-10B, else id)
History sorting:
- OpenClaw-imported messages always appear before native messages
- Sort by CASE WHEN tag='openclaw-import' THEN id-10000000000 ELSE id END
- Cursor-based paging updated from beforeId/afterId to beforeSortKey/afterSortKey
- All history queries (GetLatestActive, Before, After, CountBefore) updated
Frontend:
- Dashboard: new 'OpenClaw Import' menu item in session card dropdown
- Modal: shows OpenClaw sessions with metadata, summary, preview messages
- Imported messages display blue 'OC' badge in chat
- API functions: apiGetOpenclawSessions, apiImportOpenclawSession
- History paging updated to use sortKey cursors
BuildReviewMessages() komplett umgebaut:
- Tool-Calls und Tool-Results werden nicht mehr übergeben
- Nur noch die reine Text-Konversation (user/assistant) wird extrahiert
- Aufeinanderfolgende Messages gleicher Rolle werden zusammengeführt
- Korrekte user/assistant-Abwechslung sichergestellt
- Fallback wenn nur Tool-Calls ohne Text vorhanden
- Unnötigen Serialisierungs-Roundtrip für Rollen-Prüfung entfernt
Erwartete Token-Ersparnis: 50-100k+ Input-Tokens pro Review-Runde
bei typischen Worker-Sessions mit vielen write_file/edit_file-Calls.
ARCHITECTURE.md:
- Inhaltsverzeichnis-Nummerierung korrigiert (22-28 statt doppelt 20-21)
- ServerSettingsEndpoint.cs in Projektstruktur ergänzt
- Tabellenbeschreibungen vervollständigt (users, agents, sessions, chains,
messages, cronjobs) mit allen fehlenden Feldern
- ChainRecord/MessageRecord/SessionWithStats Felder aktualisiert
- AutoCommit mention-Beschreibung korrigiert
ARCHITECTURE_QUICK.md:
- ToolService 12 → 13 Tools korrigiert
- Tabellenbeschreibungen analog zur Hauptdoku aktualisiert
Nach dem Streaming werden alle .streamed Elemente entfernt und pollHistory()
rendert die Messages neu aus der DB. Bisher wurden Review-Agent-Messages dabei
als einzelne Bubbles dargestellt (jeder Text-Block + jeder Tool-Call separat),
statt als eine zusammenhängende Review-Bubble wie beim Streaming.
Lösung: _renderMessagesIntoFragment() erkennt jetzt Messages mit tag-Feld
(review/preparer/finalizer) und gruppiert aufeinanderfolgende Messages mit
demselben Tag. _renderReviewGroup() erzeugt daraus eine einzige Review-Bubble
mit Header (Icon + Agent-Name), Tool-Use-Indikatoren und zusammengefasstem
Text-Content - identisch zur Streaming-Darstellung.
Fallback für alte Messages ohne tag-Feld bleibt bestehen (_isReviewMessage).
- esc() um "→" Escaping erweitert (Bug: Anführungszeichen in value="..."-Attributen brachen HTML)
- cache_control: ephemeral zu RunAgentChat() hinzugefügt (Preparer/Review/Finalizer hatten kein Prompt Caching)
- cache_control: ephemeral zu ChatNonStreaming() hinzugefügt (Telegram hatte kein Prompt Caching)
- Trailing-Leerzeile in commands-ui.js bereinigt
- ImageService: PNG-Encoder durch WebP-Encoder ersetzt (Quality 80)
- Bilder werden jetzt immer zu WebP konvertiert (auch kleine)
- DB-Migration: Bestehende PNG/JPEG-Avatare und Session-Images
automatisch zu WebP konvertiert beim Start
- Migration ist idempotent (überspringt bereits konvertierte Bilder)
- Kein Frontend-Code betroffen (Data-URLs sind format-agnostisch)
- Archive messages (loadLatestArchive) now render reply, delete, mark
and share buttons, matching the behavior of _renderMessagesIntoFragment
- Add review-bubble and preparer-bubble detection for archive messages
- Add data-role, data-timestamp attributes for proper reply quoting
- Add isMarked/deletedOn CSS class handling for archive messages
- Also add [Preparer:] to isReviewMsg check in _renderMessagesIntoFragment
for consistency
Kernproblem: Claude vergisst [FORWARD]-Tag → Preparer leitet nie weiter.
Lösung - Logik umgedreht:
- Jede Antwort wird automatisch an Session-Agent weitergeleitet (Default)
- Nur bei explizitem [QUESTION]-Tag wird gestoppt (Rückfrage an User)
- [FORWARD] wird weiterhin erkannt und entfernt, ist aber optional
Weitere Fixes:
- Preparer bekommt eigene History mit includeTag='preparer',
damit er den Kontext seiner vorherigen Rückfragen sieht
- Session-Agent bekommt saubere History ohne Sub-Agent-Messages
(nach Preparer-Phase frisch aus DB geladen)
- [QUESTION] wird im Frontend-Markdown ausgeblendet
- MessageRecord: neues Tag-Feld (null=normal, preparer/review/finalizer=Sub-Agent)
- DatabaseService: Migration tag-Spalte, INSERT-Statements erweitert
- AnthropicService: RunAgentChat setzt Tag=agentType bei allen 4 SaveMessage-Aufrufen
- ChatService: BuildHistoryFromDb filtert getaggte Messages aus API-History
Sub-Agent-Messages bleiben in der DB (Frontend-Anzeige), werden aber
nie an die Claude API geschickt – löst das Problem für Preparer,
Review und Finalizer gleichermaßen.
- Neues optionales Session-Feld 'preparerAgentId' (DB + Model + API)
- PreparerContext im ChatContext für Agent-Konfiguration
- RunPreparer() in AnthropicService: führt Preparer vor dem Worker aus
- [FORWARD] → aufbereiteter Prompt wird an Session-Agent weitergegeben
- Ohne [FORWARD] → Rückfrage an User, Flow stoppt (preparer_query)
- Preparer-System-Prompt: erklärt Rolle, [FORWARD]-Mechanismus, Vorarbeit
- Preparer kann eigene Tools + Fähigkeiten aktiv nutzen
- ChatEndpoint: Preparer-Phase vor StreamChat integriert
- Frontend: SSE-Events (preparer_start/text/tool_use/done)
- Preparer-Bubble (Info-Farbe) mit Status Weitergeleitet/Rückfrage
- [Preparer: Name] → hübscher Header, [FORWARD] ausgeblendet
- [Vorbereitet von Name] → dezenter Header in User-Bubble
- Agent-Picker im Session-Form (vor Review-Agent)
- SystemPromptBuilder.BuildBlocks/Build bekommt planMode-Parameter
- Im Plan-Modus: Tools-Block zeigt nur Read-only-Tools (read_file, list_files, glob, grep)
- Im Plan-Modus: KRITISCH, Verhalten, Erinnerung und Git-Blöcke werden übersprungen
- Im Plan-Modus: Skills als 'nicht ausführbar' markiert
- Plan-Modus-Block zentral im SystemPromptBuilder statt doppelt in AnthropicService + SessionEndpoint
- ChatService reicht planMode an SystemPromptBuilder durch
- SessionEndpoint reicht planMode Query-Parameter an BuildBlocks durch
- System-Prompt-Modal zeigt korrekte Blöcke je nach Plan-Modus-Status
- Toggle-Button (🗺️) im Chat-Input-Bereich neben Explorer
- Plan-Modus wird per ChatRequest.planMode an Backend gesendet
- Backend: Write-Tools gefiltert (nur read_file, list_files, glob, grep,
todo_write, memory_*, ask_user_choice bleiben), System-Prompt-Block
ergänzt der Änderungen verbietet, tool_choice nie 'any' erzwungen
- ChainRecord.PlanMode: pro Chain gespeichert (informativ für History)
- Chain-Meta-Badge '📋 Plan-Modus' bei Plan-Chains
- Choice-Response erbt planMode vom vorherigen Chain
- CSS: .plan-mode-active Styling (Primary-Color Highlight)
- Placeholder wechselt zu 'Plannen...' wenn aktiv
- Plan-Modus wird bei Session-Wechsel zurückgesetzt
- Dashboard: 'Rückfragen'-Badge (🔵) bei Agent-Card wenn allowUserChoice aktiv
- SystemPromptBuilder: Hinweis-Block der Claude anweist, ask_user_choice sparsam zu nutzen
- Neues Feld AllowUserChoice (bool, default true) im AgentRecord
- DB-Migration: allow_user_choice Spalte mit DEFAULT 1
- Agent-Form: Checkbox 'Rückfragen erlauben' nach 'Tool-Nutzung erzwingen'
- ToolService.GetToolDefinitions: neuer Parameter includeUserChoice
- ask_user_choice Tool wird nur eingebunden wenn Agent es erlaubt
- Review-Agents und Non-Streaming (Cronjobs) erhalten nie ask_user_choice
- ChatEndpoint reicht Agent.AllowUserChoice an StreamChat durch
Neues Tool 'ask_user_choice' analog zum AskUserQuestion aus dem Claude Agent SDK.
Claude kann dem User Multiple-Choice-Fragen stellen, wenn es mehrere sinnvolle
Wege gibt. Der User wählt per Button, Claude arbeitet mit der Antwort weiter.
Backend:
- ToolService: ask_user_choice Tool-Definition (question + choices[2-5])
- AnthropicService/ProcessStream: Tool wird NICHT ausgeführt, sondern als
SSE-Event 'user_choice' an den Client gesendet. stopReason wird auf
'awaiting_user_choice' gesetzt (mit Guard gegen Überschreibung durch
message_delta)
- ChatEndpoint: Erkennung von Choice-Responses (choiceToolCallId + choiceResult),
tool_result wird in die korrekte Chain gespeichert (wo der tool_use liegt),
toolChoice wird auf 'auto' gesetzt damit Claude frei antworten kann
- ChatService: FindChainWithToolCall() zum Auffinden der richtigen Chain,
BuildHistoryFromDb() erweitert um Choice-Chain-Erkennung (wenn letzte Chain
leer/nur tool_result → vorletzte Chain vollständig rekonstruieren)
- ChatModels: ChatRequest um ChoiceToolCallId + ChoiceResult erweitert
Frontend:
- api.js: apiChatChoice() für Choice-Responses
- chat.js: handleStreamEvent() als shared Handler extrahiert (sendMessage +
handleChoiceClick nutzen denselben Code), handleChoiceClick() startet neuen
Stream nach Button-Klick
- ui.js: addChoiceBubble() (live/interaktiv) + addChoiceBubbleStatic() (History)
- history.js: Choice-Bubbles in _renderMessagesIntoFragment + renderMessages,
Voraus-Suche nach zugehörigem tool_result, unbeantwortet = klickbare Buttons
- chat.css: Styling für Choice-Bubbles (Primary-Color-Outline-Buttons, Hover,
Selected/Unselected States)
Robustheit:
- Backend-Fallback wenn Claude choices als String statt Array sendet
- Frontend-Guard: Array.isArray(choices) an allen 4 Render-Stellen
- Page-Refresh mit offener Choice → aktive Buttons werden korrekt gerendert
- history.js: _mergeConsecutiveAssistantTexts überspringt web_search_result
Messages beim Suchen des vorherigen Text-Blocks, sodass Text vor und
nach einer Web-Search in der History als eine Bubble gerendert wird
- Text-Blöcke werden mit doppeltem Zeilenumbruch statt Leerzeichen
zusammengefügt (besseres Markdown-Rendering)
- chat.css: web_search Tool-Box von Opacity-Regel ausgenommen
- chat.js: _afterWebSearch Flag trackt ob gerade eine Web-Search beendet wurde
- text_start nach Web-Search: resumeStreamBubble() statt neue Bubble
- web_search_start: Bubble NICHT beenden (bleibt finalisiert im DOM)
- web_search_end: setzt _afterWebSearch=true
- Flag wird bei tool_start, review_start, finalizer_start, error, done zurückgesetzt
- ui.js: Neue resumeStreamBubble() Funktion
- _lastStreamDiv/_lastStreamText speichern letzte finalisierte Bubble
- resumeStreamBubble() reaktiviert die letzte Bubble zum Weiter-Streamen
- Verhindert separate Message-Blöcke bei mehrfachen Web-Searches
- Program.cs: Port aus Config lesen mit Fallback 19000
- appsettings.json: Port: 19000 als Default
- ServerSettingsEndpoint: Port als erste Einstellung (mit Neustart-Hinweis)
- Session hat optionalen ReviewAgentId + MaxReviewIterations
- Nach end_turn des Worker-Agents wird der Review-Agent aufgerufen
- Review-Agent bekommt Worker-Konversation als Kontext + kann Tools nutzen
- [APPROVED] in Review-Antwort → fertig, sonst Feedback an Worker
- Worker korrigiert und wird erneut reviewed (max N Runden)
- SSE-Events: review_start, review_text, review_tool_use, review_feedback, review_approved
- Chat-UI: Review-Phase als eigene Bubble mit Header, Text, Status
- Session-Page: Review-Agent-Picker (gleicher Agent-Card-Helper)
- Dashboard: Review-Agent-Badge auf Session-Cards
- DB-Migration: review_agent_id, max_review_iterations auf sessions
- ui.js: [Krea: datei] URLs von /api/skills/krea-api/output/ auf /api/images/file/ geändert
- KreaEndpoint: GET /api/images/file/{filename}/thumb mit gecachten WebP-Thumbnails (320px)
- Thumbnail-Cache in data/cache/images/, analog zum SkillEndpoint
- AuthMiddleware: X-Api-Key Header-Prüfung für /api/images/* Routen
- Neues Config-Feld KreaApiKey in appsettings.json
- Bei gültigem API-Key wird Request ohne Cookie-Auth durchgelassen
- Normaler User-Auth funktioniert weiterhin als Fallback
- ARCHITECTURE.md + ARCHITECTURE_QUICK.md aktualisiert
- Backend gibt nur Token zurück statt fertigen Link
- Frontend baut Link via window.location.origin zusammen
- Zeigt korrekte Domain/Port statt internes http://127.0.0.1
Backend:
- AdminEndpoint: POST /api/admin/users/{userId}/login-link gibt { token }
- AuthEndpoint: GET /api/auth/autologin?token=xxx setzt Cookie + redirect
- AuthMiddleware: autologin-Route von Auth ausgenommen
Frontend:
- api.js: apiAdminGetLoginLink() Funktion
- admin-page.js: Login-as-User Button → Login-Link Button mit Modal
- form.css: Styling für Login-Link Modal
- buildSessionCard(session, agent) Helper in ui.js (analog zu buildAgentCard)
Erzeugt .card mit Avatar, Name, Badges (Agent, Kontext, Telegram) und Meta (Nachrichten, Archiv, Workspace)
- Dashboard refactored: Session-Cards nutzen buildSessionCard() statt inline HTML
- Cronjob-Formular: <select> für Session und Benachrichtigungs-Session durch
klickbare Session-Cards + Picker-Modal ersetzt
- openSessionPickerModal() mit filterWithAgent-Option (Session-Dropdown nur
Sessions mit Agent, Notify-Dropdown alle Sessions)
- CSS: .session-select-card und .session-select-change Klassen analog zu agent-*
- buildAgentCard() Helper in ui.js erstellt (wiederverwendbar für Dashboard + Picker)
- Session-Form: select-Dropdown durch klickbare Agent-Card ersetzt
- Agent-Picker-Modal zeigt alle Agents mit identischen Cards wie am Dashboard
- Dashboard refactored: nutzt buildAgentCard() statt dupliziertem Inline-HTML
- Kein duplizierter Code mehr für Agent-Card-Rendering (Badges, Skills, Avatar)
Meleki