RichardandClaude Opus 5
6218a04fe4
Der Status des Projekts stand verstreut in elf Umsetzungsplaenen, drei Konzepten, der Linux-Analyse und dem Projektstand - teils widersprechend, teils wochenlang veraltet. Ab jetzt gibt es genau eine Statusquelle. docs/ROADMAP.md (neu): - Alle Vorhaben in vier Stufen A bis D, plus technische Schuld und Verlauf. Die Stufen sind eine Reihenfolge, keine Termine: jede schafft die Voraussetzung fuer die naechste. - Statuszeichen: erledigt / offen / blockiert (mit Ursache) / bewusst zurueckgestellt / Idee, nicht beschlossen. Damit ist das, was wir NICHT bauen wollen, sichtbar vorgehalten statt unauffindbar in einem Plan zu schlummern. - Inhaltlich getragen, nicht nur verlinkt: je Vorhaben Ziel, Phasen, Akzeptanzkriterien, offene Entscheidungen und Leitplanken aus den Quelldokumenten. - Sichtbar gemacht, was vorher zwischen den Dokumenten verborgen lag: CopyTrading Phase 1 ist der Engpass der gesamten Roadmap (MarketMaking und BundleArbitrage haben harte Voraussetzungen darauf), und die Sniper-Metriken aus Phase 3.2 sind ein Spezialfall des StrategieDrift-Fingerprints - zusammen bauen statt doppelt. Archiv (docs/archiv/): - 15 Dokumente verschoben (11 Umsetzungsplaene, 3 Konzepte, ANALYSE-Linux-Portierung). Sie bleiben die Bauanleitungen mit Code-Bezuegen, Risikotabellen und Begruendungen - eingefroren ist nur ihr Status. - archiv/README.md ordnet jedes Dokument seinem Roadmap-Punkt zu. Verweise nachgezogen - der eigentliche Aufwand: - 25 Markdown-Links repariert. 15 davon verschiebungsbedingt (eine Ebene tiefer), der Rest war schon vorher falsch: die Ideensammlung verlinkte Quellcode relativ zum Repo-Wurzelverzeichnis statt zu docs/. - 12 Dateien ausserhalb von docs/ verwiesen in Kommentaren auf die Plaene (csproj, props, setup.json, sechs Quelldateien) - alle auf archiv/ umgebogen. - Verweise auf Dateien, die der Fruehjahrsputz geloescht hat (Ui/, Program.cs, WindowMenuBar), zu Klartext entschaerft statt tote Links zu lassen. - Gegenprobe: 85 Links geprueft, 0 kaputt. Build gruen, 476 Tests gruen. PROJEKTSTAND.md entdoppelt: Abschnitt "Offen" verweist jetzt auf die Roadmap. Arbeitsteilung ist damit klar - Projektstand sagt was IST, Roadmap was KOMMT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.6 KiB
Lokaler NuGet-Feed (lib/nuget)
Hier liegen Pakete aus unseren eigenen Schwester-Projekten, die PolyTrader benutzt.
Aktuell genau eines: Deploymentcenter.Client (Lizenz, Watchdog, Fehler-Reporting, Updates).
Bis zum 22.08.2026 lag hier zusätzlich
LicenseLabrador.Client. Das Paket ist mit dem Ausbau der WinForms-Anwendung entfernt worden — Lizenzprüfung und Heartbeat laufen vollständig über das Deploymentcenter (siehedocs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md, Schnitt D-6). Der letzte Stand mit LicenseLabrador liegt im Git-Tagwinforms-final.
Warum ein Paket und keine Projektreferenz?
Eine ProjectReference direkt nach ..\..\Deploymentcenter\client-dotnet\... würde die
Repos hart koppeln: PolyTrader baute dann nur noch auf einer Maschine, auf der das
Schwester-Repo zufällig daneben liegt — ein Build-Server oder das Zielland-System hätte
den Build nicht mehr übersetzen können.
Die Projekte bleiben eigenständig. Deshalb wird das SDK als versioniertes
NuGet-Paket in dieses Verzeichnis gelegt und mitversioniert. Ein reiner DLL-Verweis
wäre nicht ausreichend: das Paket trägt die transitiven Abhängigkeiten in seinen
Metadaten, eine nackte DLL nicht. Zusätzlich liefert es unter build/ die
Deploymentcenter.BuildInfo.targets mit, die beim Bauen die Klasse
PolyTrader.Core.BuildInfo (Version, Git-Commit, Build-Datum) erzeugt.
NuGet.Config bindet dieses Verzeichnis als Quelle local ein. Das
packageSourceMapping löst Deploymentcenter.* ausschließlich lokal auf, damit
ein gleichnamiges Paket auf nuget.org unsere Version nicht verdrängen kann
(Dependency Confusion).
Neue SDK-Version übernehmen
-
Im Deploymentcenter-Repo die
<Version>inclient-dotnet/Deploymentcenter.Client/Deploymentcenter.Client.csprojanheben (gleiche Version zweimal zu packen führt zu stillen Cache-Treffern — NuGet unterscheidet Pakete nur an der Versionsnummer). -
Paket bauen:
dotnet pack J:\Softwareprojekte\Deploymentcenter\client-dotnet\Deploymentcenter.Client\Deploymentcenter.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget -
In
src/PolyTrader.Core/PolyTrader.Core.csprojdieVersionderPackageReferenceauf die neue Nummer setzen. -
Die alte
.nupkglöschen, damit klar bleibt, welche Fassung gilt. -
dotnet build+dotnet test— und die neue.nupkgmit committen.
Wichtig: Die Änderung am SDK gehört zuerst ins Deploymentcenter-Repo und wird dort committet. Dieses Verzeichnis ist nur die Auslieferung, nicht der Arbeitsort.