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>
Der Changelog seit 2.6.0 nennt sechs Fassungen, 16 action_items und fuenf
brechende Aenderungen. Davon trifft fast nichts diese Anwendung - und das
ist ein Befund, kein Versaeumnis:
- finding_status (brechend, 2.7.0): kein Aufrufer. Weder
/api/supervisor/v1/observe noch /status werden hier angesprochen.
Vorgemerkt fuer #528 Stufe 3 - wer den Manager baut, liest den
Befundzustand von Anfang an aus diesem Feld.
- Nachpruefungs-Status awaiting_verification, in_verification,
fix_insufficient (brechend, 2.6.1): Die Anwendung wertet
bugtracker_items.status nirgends aus. Betrifft den Arbeitsablauf der
Agenten, und der steht in CLAUDE.md bereits richtig beschrieben.
- Meldungen ohne project_slug (brechend, 2.8.1): BugtrackerClient und
ErrorReporter schicken project_slug und build_version seit jeher mit.
- Leseweg ohne project_slug und schmales dc_roadmap (brechend, 2.8.1):
betrifft den MCP-Adapter, nicht den Anwendungscode.
Geblieben ist die eine Zusage, die man nicht sieht, wenn man sie verletzt:
Seit 2.8.1 erbt ein Watchdog-Monitor das Projekt seines Ping-Tokens. Ohne
Bindung landen die Befunde im Scheinprojekt "default", und eine Abfrage
nach dem eigenen Projekt liefert fuer eine laufende, fleissig meldende
Instanz null Befunde - die Aufsicht sieht aus wie "nichts auffaellig". Das
ist genau die Falle, in die hier schon einmal Meldungen gelaufen sind.
Deshalb neu: TokenProvisioner.WhoAmIAsync gegen GET
/api/tokens/v1/whoami (SDK 2.7.1) und der Typ TokenIdentity mit
IsProjectBound. DeploymentcenterService fragt beim Start das eigene
Melde-Token, protokolliert das Projekt und warnt, wenn keines dransteht.
Bewusst nur eine Warnung: Monitoring, das bei unklarer Rechtelage gar nicht
erst anlaeuft, ist genau dann still, wenn man es braucht. Faellt die
Auskunft aus - aelterer Server, kein Netz -, bleibt es bei Debug.
Gemessen statt geraten: TokenProvisioner schickt keinen project_slug mit,
und ob der Server die Bindung vom Master-Token erbt, steht in keiner
Beschreibung, die vorliegt. Ein Sub-Token dafuer eigens auf dem
Produktivserver auszustellen waere zu viel Nebenwirkung gewesen; die erste
Instanz, die eines zieht, sagt es jetzt selbst ins Protokoll.
#176 ist erledigt und die Regel in CLAUDE.md gestrichen: dc_roadmap ohne
project_slug liefert jetzt das eigene Projekt (nachgemessen: 51 Eintraege,
alle clawddotnet). Wer projektuebergreifend lesen will, schickt
project_slug=all.
dc_link_project auf 2.8.2 gesetzt, CLAUDE.md-Zeile hochgesetzt.
Build ohne Warnungen, 717 Tests gruen, 8 uebersprungen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- ClawdDotNet.Web: Kestrel im Prozess der Anwendung, Token-Absicherung (TokenGate mit FixedTimeEquals), Endpunkte unter /api, Ereignisstrom unter /events (Server-Sent Events) und fortlaufendes Log-Streaming.
- Weboberflaeche (wwwroot/): Vollstaendiges Single-Page-Frontend mit nativem HTML5, CSS3 und ES-Modulen ohne Buildschritt (strikt textContent, #-Routing, sofortiger Login-Sprung bei fehlendem Token, Light/Dark-Theme, lokale Barlow-Schriften).
- ClawdDotNet.App: Fachlogik aus den Avalonia-ViewModels in Dienste herausgeloest (AgentAdministration, JobAdministration, ServiceAdministration, RunCoordinator) und ueber InstanceChange synchronisiert.
- Tests: ClawdDotNet.Web.Tests und ClawdDotNet.App.Tests hinzugefuegt, alle 684 Tests erfolgreich.
