RichardandClaude Opus 5
e14dd25979
docs/pruefplaene/PRUEFPLAN-Linux-Betrieb.md: Schritt-fuer-Schritt-Protokoll zum Abarbeiten auf einer Test-VM, jeder Schritt mit erwartetem Ergebnis und der Angabe, was zurueckzumelden ist. Zwei Fallen vorab, die beim Vorbereiten aufgefallen sind: 1. Der Linux-Publish enthaelt appsettings.Local.json mit den echten MySQL-Zugangsdaten. Ungeprueft auf die VM kopiert, laeuft der Test gegen die PRODUKTIVdatenbank - und der MarketSyncService schreibt dort als Hintergrunddienst hinein. Der Plan legt deshalb zuerst eine eigene Testdatenbank samt eigenem Benutzer an; das Umstellen der Verbindung ist ausdruecklich als wichtigster Schritt markiert. 2. Es gibt keine automatischen Migrationen beim Start (nachgeprueft: kein Migrate()/EnsureCreated() im Code). Das Schema muss vorher stehen - fuenf DbContexts, jeder mit eigenen Migrationen, ueber die Umgebungsvariable POLYTRADER_MYSQL. Inhaltliche Schwerpunkte des Plans: - Die Hypothese, dass --headless OHNE GUI-Bibliotheken auskommt, weil BuildAvaloniaApp() dort nie aufgerufen wird und Skia damit nie geladen wird. Der Plan prueft das bewusst zuerst ohne die Pakete - das Ergebnis entscheidet, was spaeter ins Server-Grundimage muss. - Die WorkingDirectory-Falle aus D-11: server_settings.xml relativ zum Arbeitsverzeichnis, master.key relativ zur Programmdatei. Bei Abweichung legt ServerSettings.Load() kommentarlos eine neue Datei an. Wird per find ueber frisch geaenderte Dateien nachgewiesen. - SIGTERM-Shutdown gegen TimeoutStopSec=45 gemessen, Restart=on-failure per pkill -9 gegengetestet. - T2 (TerminalLogger stempelt DateTime.Now statt AppTimeZone) wird auf einer UTC-VM erstmals nachweisbar statt nur behauptet. - Logrotate mit copytruncate, weil die App die Logdatei offen haelt. - Master-Key als Umgebungsvariable im Dienst: erster echter Lauf von FilePermissions unter Linux-Rechten. Am Ende eine Liste der zehn zurueckzumeldenden Ausgaben und die Befehle zum Aufraeumen der VM. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
58 lines
3.2 KiB
Markdown
58 lines
3.2 KiB
Markdown
# Doku (Predictalytics / PolyTraderSharp)
|
|
|
|
Zentrale Ablage für Roadmap, Leitfäden, Fach- und Business-Dokumente. Code-gekoppelte Pläne
|
|
bleiben bewusst in **diesem** Repo (statt in einem separaten Docs-Repo), damit
|
|
„Plan → umsetzende Commits" nachvollziehbar bleibt.
|
|
|
|
## Wo anfangen?
|
|
|
|
| | |
|
|
|---|---|
|
|
| **[ROADMAP.md](./ROADMAP.md)** | **Das Steuerungsdokument.** Alle Vorhaben, Status, Reihenfolge — was als Nächstes zu tun ist und was bewusst liegen bleibt |
|
|
| **[PROJEKTSTAND.md](./PROJEKTSTAND.md)** | Der Ist-Zustand: Architektur, Kennzahlen, Modul-Stand |
|
|
|
|
Kurzformel: **PROJEKTSTAND = was ist. ROADMAP = was kommt.**
|
|
|
|
## Leitfäden (vor der Arbeit lesen)
|
|
|
|
- **[LEITFADEN-Avalonia-Portierung.md](./LEITFADEN-Avalonia-Portierung.md)** — Arbeitsregeln für
|
|
die Oberfläche. **Vor jeder UI-Arbeit lesen**: Layout ist deklarativ, keine festen Farben,
|
|
Module bleiben frei von Avalonia.
|
|
- **[LEITFADEN-CI.md](./LEITFADEN-CI.md)** — was die CI prüft und wie der Gitea-Runner
|
|
eingerichtet wird.
|
|
- **[`.agents/rules/clob.md`](../.agents/rules/clob.md)** — verbindlich für alles, was Geld bewegt.
|
|
|
|
## Struktur
|
|
|
|
- **[`archiv/`](./archiv/)** — die Umsetzungspläne und Konzepte, aus denen die Roadmap
|
|
zusammengeführt wurde. **Nicht tot:** weiterhin die Bauanleitungen mit Code-Bezügen,
|
|
Akzeptanzkriterien und Begründungen. Nur der *Status* darin ist eingefroren — dafür gilt
|
|
ausschließlich die Roadmap. Details in [`archiv/README.md`](./archiv/README.md).
|
|
- **[`sicherheit/`](./sicherheit/)** — Sicherheitskonzept und die wiederkehrende
|
|
Audit-Checkliste. Die offenen Kästchen in Abschnitt 6 sind eine **Vorlage für jedes Release**,
|
|
kein Rückstand.
|
|
- **[`steuer/`](./steuer/)** — Steuer-/Buchhaltungs-Fachdokumente und Vorlagen, auch zum
|
|
Weitergeben an Berater.
|
|
- `Accounting-US-Tax-Questionnaire.md` — Fragebogen (EN) für die US-Steuerberaterin (Florida LLC).
|
|
- **[`pruefplaene/`](./pruefplaene/)** — Prüf-/Validierungspläne zum Abarbeiten.
|
|
- `PRUEFPLAN-Linux-Betrieb.md` — erster Lauf auf einer Linux-VM (Roadmap A4a).
|
|
- `PREDICTALYTICS-PRUEFPLAN-Master-Auswahl.md` — Master-Trader-Auswahl (separates
|
|
Predictalytics-Projekt).
|
|
- **`ideen/`** — frühe Ideen, bevor sie zu einem Konzept reifen.
|
|
- **[UI-SPEZIFIKATION-WinForms.md](./UI-SPEZIFIKATION-WinForms.md)** — Beschreibung der
|
|
abgelösten Oberfläche. Vergleichsvorlage für die Abnahme A5.
|
|
- **[IDEENSAMMLUNG-Feldtest-2026-08.md](./IDEENSAMMLUNG-Feldtest-2026-08.md)** — Beobachtungen
|
|
aus dem laufenden Einsatz. Nur sammeln, Umsetzung später.
|
|
|
|
## Konventionen
|
|
|
|
- **Eine Statusquelle.** Fortschritt wird ausschließlich in der Roadmap gepflegt, nirgends sonst.
|
|
Bis zum 22.08.2026 stand der Status in einem Dutzend Dokumenten — mehrere davon waren
|
|
wochenlang falsch.
|
|
- **Plandokument und Code wandern im selben Commit.** Wer etwas abhakt, committet die Roadmap mit.
|
|
- Neue Detailpläne: `UMSETZUNGSPLAN-*.md` → `archiv/umsetzungsplaene/`, und in der Roadmap
|
|
verlinken. Neue Konzepte analog nach `archiv/konzepte/`.
|
|
- Ü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.
|