RichardandClaude Opus 5
740649789e
Der Stand lag ueber eine Bestandsaufnahme, drei Konzeptpapiere, vier Umsetzungsplaene und zwei Deploymentcenter-Dokumente verteilt - jedes mit eigener Reihenfolge, teils widersprueglich. Alle offenen Punkte daraus sind in docs/Roadmap.md zusammengefuehrt. Aufbau der neuen Roadmap - Statusvokabular: erledigt / beschlossen-offen / Entscheidung noetig / zurueckgestellt / Idee. Damit steht das Geparkte sichtbar drin, statt in einem Konzeptpapier zu verschwinden. - Herkunft-Spalte traegt das alte Kuerzel (S4, K2, B9, T4, F-A1, C1, DC1), damit die archivierten Papiere auffindbar bleiben, ohne sie zu lesen. - Abschnitt 1 Reihenfolge, 2 offene Entscheidungen, 3 die Vorhaben nach Bereich, 4 Ideenspeicher, 5 Chronik des Erledigten, 6 Modell-Einstufung, 7 Herkunftskarte. Was dabei sichtbar wurde - Neun Entscheidungen blockieren Arbeit, ohne dass sie Aufwand kosten - allen voran Matrix oder Rocket.Chat. Sie stehen jetzt gesammelt in Abschnitt 2 statt verstreut in den Diskussionsteilen der Konzepte. - B8 (keine Tiefenbegrenzung bei AgentComm) ist unveraendert offen. Das ist keine Theorie: A haelt sein Gate, waehrend es auf B wartet - ruft B nun A, warten beide bis zum Timeout. Der Testfall A13 dafuer fehlt bis heute. - Die vier Umsetzungsplaene vom 2026-08-05 sind alle unumgesetzt und waren in keiner Roadmap verzeichnet. Archiv Sechs Dokumente ziehen nach docs/archiv/: Bestandsaufnahme, Konzepte Backup/Finanz/Analyse, Linux-Portierung-Analyse, Lizenz-HardwareId-v2 (gegenstandslos - LicenseLabrador ist ersetzt), Deploymentcenter-Review und der 2.4-Integrationsplan. Sie bleiben als Begruendung lesbar, werden aber nicht mehr fortgeschrieben; das README ordnet jedes einzeln ein und warnt, dass ihre Quelltext-Verweise ins Leere gehen koennen. Bauplan bleibt Bauplan Taskboard, Audit, Staging, Memory, Agentenkommunikation, RocketChat und Deploymentcenter-Integration bleiben in docs/ - sie sind die Detailvorgabe fuer die Umsetzung, nicht Vorhabenlisten. Jedes bekommt oben eine Zeile, die seine Rolle und den Umsetzungsstand nennt und auf die Roadmap zeigt. Dasselbe fuer die vier Umsetzungsplaene: die Reihenfolge gilt in der Roadmap, nicht im Plan. Nebenbei repariert: Taskboard-Konzept und Teststrategie verwiesen auf AgentScheduler und ToolJobScheduler, die seit der Scanner-Konsolidierung geloescht sind. Alle Dokument-Verweise in docs/ sind geprueft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.0 KiB
4.0 KiB
Archiv
Was hier liegt, ist abgeschlossen und wird nicht mehr fortgeschrieben. Der aktuelle Stand steht ausschließlich in der Roadmap; ihr Abschnitt 7 hält fest, was aus jedem dieser Dokumente dorthin übernommen wurde.
Aufgehoben werden sie, weil sie die Begründung tragen: warum das System so geschnitten ist, wie es geschnitten ist, und welche Befunde die Entscheidungen geformt haben. Diese Herleitung lässt sich in einer Vorhabenliste nicht unterbringen, ohne sie unlesbar zu machen.
Verweise auf Quelltext können ins Leere gehen. Viele dieser Papiere zeigen auf Dateien der WinForms-Fassung (
frm_*.cs,UI/,Models/,Program.cs) oder auf die alten Scheduler — beides wurde inzwischen entfernt. Wer die Stellen sehen will, findet sie im Tagvor-fruehjahrsputz-2026-08. Die Zeilennummern wurden bewusst nicht nachgeführt: Ein archiviertes Dokument beschreibt den Stand seines Datums.
Befunde und Konzepte
| Dokument | Datum | Was es war | Warum archiviert |
|---|---|---|---|
| Bestandsaufnahme-2026-07 | Juli 2026 | Vollständiges Review von Engine, Sicherheit, Tools, Scheduling und Oberfläche. Quelle der Kürzel S1–S7, B1–B14, K1–K6, T1–T9, F-A1…F-A7 | Erledigtes steht in Roadmap 5, Offenes in 3.1/3.2/3.7. Die Kürzel leben in der Herkunft-Spalte weiter |
| Konzepte-Backup-Finanz-Analyse | Juli 2026 | Drei Konzepte: Sicherung, Finanzumfeld, Leistungsmessung | Sicherung ist gebaut; der Rest läuft als C1–C8 weiter |
| Linux-Portierung-Analyse | 2026-08-06 | Was kostet der Umzug nach Linux | Der teure Teil — 8.900 Zeilen WinForms — ist mit der Avalonia-Portierung entfallen. Übrig bleiben drei Kernstellen (DPAPI, Pfadvergleiche, Zeitzonen-IDs), sie stehen in Roadmap 3.5 |
| Lizenz-HardwareId-v2 | 2026-08-06 | Überarbeitung der Hardware-Erkennung für LicenseLabrador | Gegenstandslos. LicenseLabrador ist durch das Deploymentcenter ersetzt. Lesenswert bleibt Abschnitt 1: warum der Rechnername nicht in eine Hardware-Kennung gehört |
| Deploymentcenter-Anbindung-Review | 2026-08-08 | Review der ersten Anbindung | Befunde behoben; die Verdrahtung beschreibt heute Deploymentcenter-Integration |
| Deploymentcenter-2.4-Integrationsplan | 2026-08-15 | Zugangsschutz, Release-Strecke, Update, Erstinstallation, Signatur — durchgearbeitet | Abgearbeitet bis auf DC8 und zwei Betreiberpunkte; die stehen in Roadmap 3.5. Enthält die Messprotokolle der live durchgespielten Setup- und Update-Kette |
Entwicklungs-Prompts der Anfangszeit
Mai–Juli 2026. Sie haben ClawdDotNet aufgebaut und beschreiben deshalb den Stand von damals — unter anderem eine WinForms-Oberfläche mit WebView2, die es nicht mehr gibt.
| Dokument | Was darin steht | Was davon noch gilt |
|---|---|---|
| ClawdDotNet_StartPrompt | Gesamtentwurf, Kernklassen, Beispielkonfiguration | Der Schichtschnitt Core/Tools/App und der Tool-Vertrag stammen von hier. Oberfläche und configs/*.json sind überholt |
| ClawdDotNet_Prompt_WebviewChatWinForms | WinForms-Oberfläche mit WebView2-Chat | nichts — ersetzt durch src/ClawdDotNet.Desktop |
| ClawdDotNet_Prompt_TelegramClient | Entwurf des TelegramClient-Tools | umgesetzt in src/ClawdDotNet.Tools.TelegramClient |
| ClawdDotNet_Prompt_InternetTools | WebFetch, DirectAPI, WebMonitor | Eine Regel gilt weiter: die Pflichtfelder fetchedAt / dataAsOf / source in jedem Tool-Ergebnis mit externen Daten. Der WebSearch-Umsetzungsplan verweist darauf. Zieht diese Regel in ein eigenes Dokument um, kann die Datei ganz weg |