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>
50 lines
2.6 KiB
Markdown
50 lines
2.6 KiB
Markdown
# 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 (siehe
|
|
> `docs/archiv/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md`, Schnitt D-6).
|
|
> Der letzte Stand mit LicenseLabrador liegt im Git-Tag `winforms-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
|
|
|
|
1. Im Deploymentcenter-Repo die `<Version>` in
|
|
`client-dotnet/Deploymentcenter.Client/Deploymentcenter.Client.csproj` **anheben**
|
|
(gleiche Version zweimal zu packen führt zu stillen Cache-Treffern — NuGet
|
|
unterscheidet Pakete nur an der Versionsnummer).
|
|
2. Paket bauen:
|
|
|
|
```
|
|
dotnet pack J:\Softwareprojekte\Deploymentcenter\client-dotnet\Deploymentcenter.Client\Deploymentcenter.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget
|
|
```
|
|
|
|
3. In `src/PolyTrader.Core/PolyTrader.Core.csproj` die `Version` der `PackageReference`
|
|
auf die neue Nummer setzen.
|
|
4. Die alte `.nupkg` löschen, damit klar bleibt, welche Fassung gilt.
|
|
5. `dotnet build` + `dotnet test` — und die neue `.nupkg` mit 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.
|