RichardandClaude Opus 5
4ba8149e64
Der PropertyGrid-Ersatz ist EIN wiederverwendbares Steuerelement statt Handarbeit je Feld: Controls/SettingsEditor zeigt ein beliebiges Einstellungsobjekt nach Richards Vorlage - Kategorie-Ueberschrift, Beschriftung links, Feld rechts, Erklaerung klein darunter. - SettingsModelBuilder liest die Attribute, die fuers PropertyGrid ohnehin gepflegt waren: [Category] gruppiert, [DisplayName] beschriftet, [Description] wird zum Hinweistext, [Browsable(false)] blendet aus (Watchdog-Token, Lizenzschluessel bleiben unsichtbar). Ergebnis fuer ServerSettings: 6 Abschnitte, 15 Felder - ohne eine Zeile Feld-Code. - Layout-Regel gewahrt: WELCHE Felder es gibt, kommt als Daten; WIE ein Feld aussieht, steht deklarativ als DataTemplate je Feldtyp (Text/Zahl/Ja-Nein/Auswahl/Nur-Lese). - Damit sind auch die drei restlichen PropertyGrid-Stellen (Account-Einstellungen, Master-Trader, ResolutionFarming) mit je einem Aufruf erledigt. SettingsWindow: Server-Settings + Polymarket-Accounts, Master-Key erzeugen, OpenRouter-Key/Watchdog-Token setzen, Test-Heartbeat. Rueckmeldungen laufen ueber die Statuszeile statt ueber Dialoge - nur echte Entscheidungen bekommen einen Dialog (neu: Views/DialogWindow fuer Hinweis/Rueckfrage/maskierte Eingabe, Avalonia hat keine MessageBox). Nebenbei einen offenen Punkt der Linux-Analyse erledigt: Schluesseldateien (master.key, openrouter.key) werden jetzt per File.SetUnixFileMode auf 600 gesetzt. Auf Linux legt File.WriteAllText sonst mit ueblicher umask 644 an - weltweit lesbar. Lizenzdialog bewusst NICHT portiert: haengt am alten LicenseLabrador-SDK, das mit der Deploymentcenter-Anbindung (P3c) ohnehin ersetzt wird - waere Wegwerfarbeit. Smoke-UI prueft jetzt zusaetzlich die Feldzahl des Editors: ein Fenster kann fehlerfrei konstruieren und trotzdem leer sein, wenn die Attribute verlorengehen. Verifiziert: Solution baut, 442 Tests gruen, --smoke-ui gruen (5 Fenster + Editor-Pruefung), Linux-Publish laeuft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Doku (Predictalytics / PolyTraderSharp)
Zentrale Ablage für Konzepte, Umsetzungspläne, Ideen und Fach-/Business-Dokumente — nach Typ in Unterordnern organisiert. Code-gekoppelte Umsetzungspläne bleiben bewusst in diesem Repo (statt in einem separaten Docs-Repo), damit „Plan → umsetzende Commits" nachvollziehbar bleibt.
Struktur
konzepte/— Konzepte für neue Module/Features (das „Warum" und „Was", vor der Umsetzung).KONZEPT-Modul-Accounting.md— Buchhaltungs-/Steuer-Reporting-Modul (unabhängiger Polymarket-Abruf, BWA, CSV/PDF, US-Steuer Florida LLC).KONZEPT-Modul-DataDriven.md
umsetzungsplaene/— konkrete, slice-weise Implementationspläne (das „Wie"), oft mitfile:line-Bezügen und Fortschritt.UMSETZUNGSPLAN-Modularisierung.md— Umbau Copytrader → Core + Module.UMSETZUNGSPLAN-CopyTrading-Verbesserungen.md— Rentabilitäts-/Fable-Plan Copytrading.UMSETZUNGSPLAN-Fable-Review-Fixes.md— Fable-Code-Review-Fixes (Slices 0–6 + Tests).UMSETZUNGSPLAN-Modul-ResolutionFarming.md— Strategiemodul ResolutionFarming.UMSETZUNGSPLAN-Modul-MarketMaking.md— Strategiemodul MarketMaking (Phase-1-blockiert).UMSETZUNGSPLAN-Modul-BundleArbitrage.md— Strategiemodul BundleArbitrage (Phase-1-blockiert).UMSETZUNGSPLAN-AutoRedeem.md,UMSETZUNGSPLAN-AI-Aufloesequalitaet.md,UMSETZUNGSPLAN-StrategieDrift.md
ideen/— frühe Ideen/Explorationen, bevor sie zu einem Konzept oder Umsetzungsplan reifen.pruefplaene/— Prüf-/Validierungspläne.PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md— Master-Trader-Auswahl (separates Predictalytics-Projekt).
steuer/— Steuer-/Buchhaltungs-Fachdokumente & Vorlagen (auch zum Weitergeben an Berater).Accounting-US-Tax-Questionnaire.md— Fragebogen (EN) für die US-Steuerberaterin (Florida LLC).
Konventionen
- Neue Konzepte:
KONZEPT-*.md→konzepte/. Neue Umsetzungspläne:UMSETZUNGSPLAN-*.md→umsetzungsplaene/. - Übergreifende/an Externe weitergebbare Dokumente können später in ein eigenes
Predictalytics-Docs-Repo ausgelagert werden (Ordner rausziehen genügt) — für jetzt bewusst hier gebündelt.