55daa2c9def2bcf358059e8668b6da3b36293174
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
55daa2c9de |
Roadmap 0.1, 1.2 und 1.3: Key raus, Build warnungsfrei, Backfill eingegrenzt
0.1 OpenRouter-Schluessel aus appsettings.json entfernt. Laut Nutzer war er bereits inaktiv, eine Rotation beim Anbieter also nicht mehr noetig. Das Feld bleibt leer stehen, mit Hinweis daneben: der Schluessel gehoert in die Umgebungsvariable OpenRouter__ApiKey, die ohnehin Vorrang hat. Damit die Anwendung ohne Schluessel sauber laeuft, steigt OpenRouterApiClient jetzt frueh aus, statt zu senden. Vorher haette jeder Analyseversuch einen 401 erzeugt - der als Error im Fehler-Stream des Deployment Centers gelandet waere, worauf der Aufrufer die Fehlermeldung als JSON zu parsen versucht und einen zweiten Fehler erzeugt haette. Der Zustand wird einmal als Warning gemeldet. Die Konstante NotConfigured liegt im Interface, weil Application die Infrastructure-Schicht nicht referenziert. 1.2 Alle acht Nullable-Warnungen behoben, der Build ist jetzt warnungsfrei. Es waren durchweg Annotationsfragen, kein Verhalten aendert sich: * TradeRepository (6x) - die Parameterliste nimmt bewusst null auf, damit nullable Spalten als SQL-NULL geschrieben werden. Jetzt List<object?>. * TraderAnalyticsWorker - ThenInclude(o => o!.Market); der Lambda ist ein Ausdrucksbaum fuer EF und laeuft nie. * PolymarketProvider - raw.Question ?? ""; TruncateMarketStrings normalisierte den Wert einen Schritt spaeter ohnehin auf "". 1.3 Der Kategorie-Backfill holte den gesamten Marktbestand samt Event in den Speicher und verwarf den Grossteil sofort wieder. Die Einschraenkung auf Maerkte mit gefuellten Event-Tags steht jetzt in der Abfrage statt in der Schleife. Ergebnis unveraendert. Dabei einen eigenen Fehler in der Roadmap korrigiert: dort stand, dieser Backfill laufe "bei jedem Start". Das stimmt nicht - er gehoert zu RunRecalculateAllTradersAsync, der manuellen Wartungsaktion, die nur auf Knopfdruck laeuft. Die Startzeit war nie betroffen. Die falsche Aussage stand auch in STATUS.md und ist dort ebenfalls richtiggestellt. Build warnungsfrei, 126 Tests gruen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
6975720dc6 |
Eine Roadmap statt neun Plandokumente; alte Plaene ins Archiv
Die offenen Punkte lagen ueber neun Dokumente verstreut, teils widersprechend, teils mit Punkten, die laengst umgesetzt waren. ROADMAP.md fuehrt sie zusammen: sechs Stufen, jeder Punkt gegen den Code geprueft. Markierung ueber eine Legende, damit Konzepte nicht mit Aufgaben verwechselt werden: dringend, eingeplant, Backlog, Konzept (durchdacht, aber bewusst nicht eingeplant), liegt beim Nutzer, verworfen. Stufen: 0 Sofort (OpenRouter-Key) - 1 Aufraeumen abschliessen (Merge nach main, Nullable-Warnungen, Startup-Backfill) - 2 Portierung abschliessen (Linux-Erstlauf und Verifikation, dann Deployment/CI) - 3 Analytik schaerfen (Strategie- Klassifikation, Backtest-Harness, Track-Record im Score, Ranking) - 4 Daten- haushalt (SQL des Nutzers) - 5 Ingest skalieren - 6 Monetarisierung vorbereiten. Ein Anhang haelt fest, was geprueft und bewusst NICHT auf die Roadmap kam, damit es nicht versehentlich wieder als Aufgabe auftaucht (Azuro/Limitless, die Marketing-Seiten, Kaltarchiv, EF Core 10). Archiv: FIXPLAN-DONE, FIXPLAN-G-Speicher, FIXPLAN-TODO, FIXPLAN-UI-Ranglisten, UMSETZUNGSPLAN sowie ANALYSE-Linux-Portierung, PLAN-Linux-Portierung, PLAN-Architektur-WebUI-Backend und PLAN-DatenIngest-Skalierung liegen jetzt unter docs/archiv/ mit einer README, die jedes Dokument einordnet. Sie bleiben als Begruendungs- und Detailquelle - die Roadmap nennt jeden Punkt knapp, die Herleitung steht dort. Dabei aufgefallen: die beiden nie gepflegten Plaene (Architektur, DatenIngest) zeigten 40 offene Punkte, von denen die Haelfte umgesetzt war - Read/Control- Split, /api/capabilities, CORS-Whitelist, Egress-Kanaele mit Cooldown und Per-Kanal-Limiter, Ingest-Tiering. Nachgeprueft, abgehakt und mit Statusblock eingeordnet, sonst waere das Archiv selbst eine Fehlerquelle. Was dabei nur teilweise umgesetzt war, ist als Roadmap 5.3 aufgenommen (Health-Statistik je Kanal, multi-homed pruefen, DB-Guard, Plausibilitaets- pruefung), ebenso der nie durchgefuehrte Audit auf versteckte Writes in Read-Endpunkten (6.1). Header-Rotation ist als verworfen markiert statt offen zu bleiben: Verschleierung gegenueber Polymarket riskiert genau den Zugang, auf dem das Projekt aufsetzt. STATUS.md beschreibt jetzt nur noch den Ist-Stand und verweist fuer die offenen Punkte auf die Roadmap, damit nichts doppelt gepflegt wird. CLAUDE.md nennt beide Einstiege. Build gruen, 126 Tests gruen, keine toten Links. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
1f230fe12c |
Fruehjahrsputz 2/2: Dokumentation auf den tatsaechlichen Stand gebracht
Die Plandokumente waren durchweg veraltet: 85 von 91 Punkten im
UMSETZUNGSPLAN standen auf offen, obwohl der Code sie enthielt, und in
FIXPLAN-UI-Ranglisten war keine einzige der 18 Aufgaben abgehakt, obwohl
beide zugehoerigen Commits laengst im Zweig stecken. Alles abschnittsweise
gegen den Code geprueft und die Haekchen gesetzt - mit Belegstellen, damit
die naechste Pruefung nicht wieder bei null anfaengt.
Neu: STATUS.md als Einstiegsseite - wo das Projekt steht, was fertig ist,
was offen ist, und was beim Aufraeumen bewusst stehengeblieben ist. CLAUDE.md
verweist darauf.
Nachgezogen:
* UMSETZUNGSPLAN.md - 66 Punkte abgehakt. Offen bleiben A4 (Strategie-
Klassifikation), B2 (Secrets) sowie C3/D1/D2 (SQL-Arbeiten des Nutzers).
* FIXPLAN-UI-Ranglisten.md - abgeschlossen bis auf den als "Optional"
markierten Pfeilrichtungs-Punkt.
* FIXPLAN-TODO.md - Teil D und F abgehakt; die Test-Baseline "16 gruen"
auf die heutigen 126 korrigiert. Offen: F5 und zwei Tests aus F6.
* FIXPLAN-G-Speicher.md - G1 bis G4 als erledigt vermerkt, Baseline "39/1"
korrigiert, Pfad auf die nicht mehr existierende WinFormsHost/appsettings.json
richtiggestellt.
* docs/PLAN-Linux-Portierung.md - der Watchdog-Warnhinweis war ueberholt
(DcHeartbeatService meldet an /api/watchdog/v1/ping). Abschnitt 11 empfahl
noch, mit Phase 0 zu beginnen; jetzt benennt er Phase 5 und 6 als das, was
wirklich aussteht. Die Randnotiz zu Zugangsdaten in LicenseGuard.cs ist
gegenstandslos, die Datei laeuft ueber den Deploymentcenter.Client.
Zwei Befunde, die keine Aufraeumarbeit sind und deshalb nur dokumentiert
wurden - beide in STATUS.md Abschnitt 3:
1. In src/Predictalytics.Api/appsettings.json steht ein echter
OpenRouter-API-Key im Klartext, versioniert seit
|