RichardandClaude Opus 5
6975720dc6
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>
121 lines
4.0 KiB
Markdown
121 lines
4.0 KiB
Markdown
# Predictalytics
|
|
|
|
**Zuerst hier nachsehen:**
|
|
* [`STATUS.md`](STATUS.md) — wo das Projekt steht, was fertig ist.
|
|
* [`ROADMAP.md`](ROADMAP.md) — was ansteht, in welcher Reihenfolge, und welche Konzepte
|
|
bewusst zurückgestellt sind.
|
|
|
|
Die früheren Plandokumente liegen unter [`docs/archiv/`](docs/archiv/) und werden nicht
|
|
mehr gepflegt.
|
|
|
|
Betriebsdokumentation zur Anbindung an das Deployment Center (Lizenz, Watchdog,
|
|
Updates, Fehler-Stream): [`docs/BETRIEB-Deploymentcenter.md`](docs/BETRIEB-Deploymentcenter.md).
|
|
|
|
## Zentraler Bugtracker — Deployment Center
|
|
|
|
Erfasse unbehandelte Fehler, geplante Verbesserungen und Ideen im zentralen
|
|
Deployment Center. Basis-URL: `https://dc.mhdf.de`
|
|
|
|
### Zugang
|
|
Token steht in der Umgebungsvariable `DC_TOKEN`.
|
|
Header: `Authorization: Bearer $DC_TOKEN`
|
|
|
|
Ist `DC_TOKEN` nicht gesetzt, melde nichts und weise stattdessen darauf hin —
|
|
die Endpunkte antworten sonst mit `401 unauthorized`.
|
|
|
|
Die vollständige Schnittstellenbeschreibung liegt maschinenlesbar unter
|
|
`GET /api/openapi.json`, das Handbuch unter `/docs/`.
|
|
|
|
### Projekt
|
|
Dieses Projekt ist `predictalytics`.
|
|
Repo: `http://192.168.178.10:8418/Richard/Predictalytics`
|
|
Fällt dir ein Fehler im Deployment Center selbst auf, melde ihn unter
|
|
`deploymentcenter`.
|
|
|
|
### Etwas melden
|
|
`POST /api/bugtracker/v1/report`
|
|
|
|
```json
|
|
{
|
|
"project_slug": "predictalytics",
|
|
"type": "bug",
|
|
"title": "Kurze, aussagekräftige Zusammenfassung",
|
|
"description": "Unter welchen Bedingungen tritt es auf?",
|
|
"error_message": "Exakte Fehlermeldung",
|
|
"stack_trace": "Vollständiger Stacktrace",
|
|
"severity": "high",
|
|
"environment": "production",
|
|
"build_version": "v1.0.0",
|
|
"repo_url": "http://192.168.178.10:8418/Richard/Predictalytics",
|
|
"git_branch": "main",
|
|
"commit_sha": "a21536f",
|
|
"file_path": "src/Predictalytics.Worker/Services/TraderAnalyticsWorker.cs",
|
|
"line_no": 152,
|
|
"client_ref": "eindeutige-id-dieses-laufs"
|
|
}
|
|
```
|
|
|
|
**Setze immer `client_ref`** — ein wiederholter Aufruf mit demselben Wert legt
|
|
kein Duplikat an. Gib nach Möglichkeit `file_path` und `line_no` an; das spart
|
|
dem nächsten Agenten das Parsen des Stacktrace.
|
|
|
|
Schweregrade: `idea` (Gedanke für später), `wishlist` (Backlog),
|
|
`low`, `medium`, `high`, `critical`.
|
|
|
|
### Arbeit übernehmen
|
|
Bevor du an einem Item arbeitest, übernimm es — sonst arbeiten zwei Agenten
|
|
parallel am selben Problem:
|
|
|
|
```
|
|
POST /api/bugtracker/v1/manage?action=next
|
|
Body: {"project_slug": "predictalytics", "limit": 1}
|
|
```
|
|
|
|
Antwortet der Server mit `409 already_claimed`, nimm das nächste Item.
|
|
Die Reservierung läuft nach 30 Minuten ab; `action=claim` auf dieselbe ID
|
|
erneuert sie.
|
|
|
|
### Fortschritt festhalten
|
|
```
|
|
POST /api/bugtracker/v1/manage?action=comment&id=<ID>
|
|
Body: {"comment": "Was du herausgefunden hast", "action_taken": "investigated"}
|
|
```
|
|
|
|
`action_taken`: `investigated`, `fix_proposed`, `pr_opened`, `needs_human`,
|
|
`blocked`, `commented`.
|
|
|
|
### Abschließen
|
|
```
|
|
POST /api/bugtracker/v1/manage?action=resolve&id=<ID>
|
|
Body: {"resolved_in_build": "v1.0.1", "resolution_notes": "Was geändert wurde"}
|
|
```
|
|
|
|
Kommst du nicht weiter, gib das Item zurück statt es blockieren zu lassen:
|
|
```
|
|
POST /api/bugtracker/v1/manage?action=release&id=<ID>
|
|
Body: {"note": "Grund"}
|
|
```
|
|
|
|
### Laufzeitfehler
|
|
Die Anwendung meldet Error/Fatal selbst über `POST /api/errors/v1/report`
|
|
(`Services/DcErrorReporter.cs`) — dort nichts von Hand nachreichen.
|
|
|
|
### Release melden
|
|
Nach einem Release schließen sich Items mit passendem `resolved_in_build`
|
|
automatisch:
|
|
```
|
|
POST /api/updateservice/v1/publish
|
|
Body: {"product_slug": "predictalytics", "version": "1.0.1",
|
|
"download_url": "...", "sha256_hash": "...", "git_commit": "..."}
|
|
```
|
|
|
|
Die Version in `Directory.Build.props` (`<Version>`) muss dazu passen — sie ist
|
|
es, die der Client als installierte Version meldet.
|
|
|
|
### Fehlerbehandlung
|
|
Antworten haben die Form `{"status":"error","error":{"code":"…"}}`.
|
|
Reagiere auf `code`, nicht auf den Text:
|
|
- `401 unauthorized` — Token prüfen, nicht wiederholen
|
|
- `409 already_claimed` — nächstes Item nehmen
|
|
- `429 rate_limited` — Intervall verdoppeln, später erneut
|